I can’t figure out what I’m missing here… I have album art saved as albumart.jpg in each album’s folder in my music collection, and I want my Vero to use those files as the album art in my Music library.
I have verified that “Prefer online album art” is not ticked in Settings→Media→Music. But when I add albums to my library, many of them display with no albumart at all, even though I can browse the “source” network share from my PC and verify that the albumart.jpg file is present and opens fine in an image viewer.
I’ve tried rebooting, I’ve tried deleting the MyMusic database files then rebooting, I’ve tried removing the source and cleaning the library then rebooting, and I’ve tried adding entirely new albums. Still those albumart files are not picked up when I add albums and update the library.
I’m an experienced Linux user and comfortable with the command-line, I have ssh access all set up, and I’m happy to provide config info or logs… if you tell me where to find them. I’m pretty new to Kodi and OSMC.
Any pointers?
PS. Does whatever parser OSMC/Kodi uses for xml support any sort of wildcard or regex functionality? I’d love to be able to specify “case insensitive match string albumart. + any three-letter suffix” if possible… once I get past the main problem above, of course.
Also be aware during testing that Kodi will hold a cached image for 24hrs (at least that is the time I’m remembering off the top of my head) for a given file path so if you have the thought to swap some image out to make sure it is getting picked up be aware of this.
@Tom_Doyle I see from the explanation on the wiki that you can remove the default (as demonstrated in the example), but I don’t see any indication that you need to remove it rather than simply adding to it.
To be thorough, I did try adding that <remove> line, rebooting, and importing a new album my Kodi install had never seen before. No change — albumart.jpg was not picked up, and the album shows up in my library with the generic “record player” placeholder image where the album art should be.
@darwindesign For now, I have a substantial number of albums that have never been imported to my Kodi library before, so I can keep testing with fresh new imports and not have to worry about caching. Thanks for the heads-up though, I can definitely see how that would cause confusion. Do you happen to know if that caching applies to the generic placeholder image mentioned above, or only to “real” album art found by the local filesystem check and/or online scrapers?
Is there an import log I can find somewhere to determine what config it’s loading and what art sources it’s attempting in what order and so forth?
It does not apply to the placeholder image. If you turn on Kodi debug logging while you add the album then you will see expanded info in ~/.kodi/temp/kodi.log but off the top of my head I’m not sure how much.
Scratch that. I saw that is how extra art goes in but I think this setting is different. I did find a thread where it is stated these filenames are case sensitive so that may be something to check as a possible issue.
@darwindesign I tested that idea before seeing your “scratch that” edit, and still no joy.
For testing, I have a goofy placeholder image I created myself, which is named albumart.png (all lowercase, just as you see it here). Before importing each album right now during testing, I’m deleting any and all image files in the album folder, using a tag editor to remove any embedded images in the music files, and dropping my testing albumart file into the album folder.
I’m using beets to manage my music library directory structure and tags, and have it configured with the “fetchart” plugin to prioritize album art files found in the local filesystem. I also have the “kodiupdate” plugin set up, so every time I do an import in beets it triggers a library update on the Vero.
I have verified that the beets import process is behaving as expected: albumart.png gets copied into the freshly created beets/<Artist>/<Album> folder (beets/ being the “source” folder for my Kodi music library), it is the only image file in that album folder, it hasn’t been replaced with a real album art image, and Kodi’s on-screen notification shows that the library update is happily running after each beets import operation. From one newly imported album to the next, browsing to the album in Kodi shows the record-player placeholder for some, and proper album art for some (depending whether the online albumart scrape succeeded or timed out, I presume), but never my testing albumart image.
If your doing a major overhaul why not just embed the tags while your at it? I’m not familiar with beets but I can tell you that Kodi 18+ seems to work best if you you run them through Musicbrainz Picard so they get album and artist id tags from that site. You have options in that program to exclude it overwriting your own tags you specify if you want which allow for custom tweaks.
I decided to test this out myself so I found a png of goofy on the interwebs and titled it albumart.png and I placed this into a folder of an album that had not been scraped yet. I then checked the music to make sure there was no imbedded artwork. I then edited my advancedsettings.xml with the code from your OP. I then went into the settings and enabled “search for thumbs on remote shares” and disabled “prefer online album art”. I then rebooted and scraped the album. Seems to work fine for me…
Okay, I figured it out, and I’m a little embarrassed. File permissions. For reasons I haven’t yet got to the bottom of, the albumart files automatically downloaded by beets are getting created without the group read permission set, which means Kodi was able to see that the file existed, (r-x perm on the directory) but not open it. Existing files that had been copied into the network share had correct permissions, so the music would all play fine and some of the albumart files were displaying as expected. *sigh*
In case it’s helpful for anyone else finding their way here during troubleshooting, I eventually found the problem using the texturecache.py script. The script’s output showed that it was trying to load the right file from the right location… but failing.
Beets, by the way, is a batch-oriented command-line tool which, like Picard, is tightly integrated with Musicbrainz. Since it also adds all the MBID tags, I assume it’ll make Kodi just as happy.
I’m specifically hoping to avoid doing a major overhaul, by getting Kodi configured to play nicely with my existing music library schema so I can add the whole thing as a source as-is. When I’m importing albums one by one to test my configuration, it’s no problem to embed the art or rename the albumart file or whatever. Doing that to my existing library wouldn’t be a huge hassle, but it would be a hassle.
Thanks for taking the time to poke at this issue with me!
Glad you finally got it sorted. If Beets is adding MBID tags then there shouldn’t be any significant difference vs Picard AFAIK. I personally embed art just to make it more universally picked up by whichever program I’m using. It takes up more space duplicating it across all tracks but IMO storage is cheap enough nowadays it shouldn’t factor in. Once your done playing with the album scraping you will have a second project filling in all the missing artist pictures. Hopefully the artist information folder doesn’t give you problems as well.
