Kodi Community Forum

Full Version: Force kodi update of album coverart after updating embedded coverart
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
The Problem: Kodi isn't updating my album coverart.

I'm a new user, and new to the forum, so please bear with me, and provide gentle reminders on forum etiquette.

Details:

Using v16.1 package from Debian (on Kubuntu 16.10). My music collection is all flac files (~6200 files), stored in [artist]/[album]/[*.flac, "Artist - Album - Cover.jpg"], all served over SMB from a Kubuntu 16.10 server. The cover art is embedded in each flac file. Over the past few days, I used picard to add musicbrainz tags to the entire collection, and added album-based ReplayGain tags as well. I also improved some cover art, and consequently removed then re-embedded all the cover art.

I have verified the embedded cover art is present via metaflac, as well as loaded random files in VLC to ensure the new embedded coverart is displayed. So the files are sound, no pun intended. :-)

I updated. then cleaned, (repeatedly!) my library in Kodi. The new MB tags *really* helped with artist thumbs and fanart. However, kodi is still using the old version of the album coverart (the previous version of the embedded art, before I updated it), rather than using the new embedded artwork. I've also repeatedly restarted Kodi, with no effect.

It is important that it use *my* coverart rather than downloaded coverart, as mine is 100% correct and uniform.

So how can I tell Kodi (besides screaming at the TV!) that it needs to re-scan the embedded coverart?

Thanks!

Edit (20170406 0130 UTC-6): I decided to upgrade to 17.x from Kodi's Ubuntu PPA, which borked my install, requiring a purge/reinstall and deletion of ~/.kodi. So it will be a while before I have all my collections re-scanned and am able to test if this issue is still present. I'll update again at that time.
Since you (have to) wipe your music.db, and kodi rescan your music, I say that after the new scan all will be fine Smile
My understanding (which may not be 100% correct so anyone please correct me if I'm wrong) is that the image cache is updated every so often although I'm not sure of the frequency. The only way I have found to force this in the past involved tracking down the image in the cache and deleting it which also involved looking at the database to find the reference to the specific cached image. I guess you could just delete all the cached images if you have a lot of changes although it's not something that I've tried.
I'm vague on this too I'm afraid, but I am aware that there is some underlying issue, or design weakness that means users get stuck with images they don't want and can't get them to change without heroic measures.

If someone can scope out the issue - repeatable problems, features needed etc. , then that could help me when I get to look at it.
(2017-04-07, 12:07)DaveBlake Wrote: [ -> ]If someone can scope out the issue - repeatable problems, features needed etc. , then that could help me when I get to look at it.

I can do that, no problem. Maybe even submit a patch.

Anyway, I finally finished upgrading to 17.1 and getting everything set up. I then updated the embedded flac coverart for 39 albums worth of flac files, then updated and cleaned the music library. It seemed to process all the changed files, but even after restarting kodi, it still keeps using the previous version of the embedded images.

It uses the wrong cover everywhere:
--In the album
--In each song
--'get thumb' doesn't re-read the file either
--'refresh' the album doesn't re-read the file either

It does look like this is repeatable, so we have that going for us. :-)

I haven't looked at any of the code in over a year, and even then it was just cursory peek, so if you could give me some suggested starting points for peeking through the code, that'd be helpful, Dave.
Looks like the first point of interest is

master/xbmc/music/infoscanner/MusicInfoScanner.cppSad960-966)

Code:
{ // more than one piece of art was found for these songs, so cache per song
    for (VECSONGS::iterator k = album.songs.begin(); k != album.songs.end(); ++k)
    {
        if (k->strThumb.empty() && !k->embeddedArt.empty())
            k->strThumb = CTextureUtils::GetWrappedImageURL(k->strFileName, "music");
    }
}

I'm not sure yet where/how k->strThumb is set, but if it is set from a currently cached image noted in the database, then embedded coverart will *never* be updated on a library rescan. I think it makes sense that when the pathhash for the folder has changed, to go ahead and update the coverart *IF* the coverart was originally derived from ((embedded art or local art) and (not from online art)). I'll keep digging into this.

The second point of interest is

master/xbmc/music/Song.cppSad290-295)
Code:
bool CSong::HasArt() const
{
  if (!strThumb.empty()) return true;
  if (!embeddedArt.empty()) return true;
  return false;
}

Again, if strThumb isn't empty, it will never check if it has embedded coverart.

strThumb is set at master/xbmc/music/Song.cppSad157)
Code:
strThumb = item.GetUserMusicThumb(true);

The next point of interest is

master/xbmc/FileItem.cppSad2901-2944)
Code:
std::string CFileItem::GetUserMusicThumb(bool alwaysCheckRemote /* = false */, bool fallbackToFolder /* = false */) const
{

    <snip>
   return ""
}

That checks for <filename>.tbn or <foldername>.tbn, then for folder.jpg, returning the first it finds, or an empty string if none are found.

That means that in my use case (embedded art, with no folder.jpg, <filename>.tbn or <foldername>.tbn) that empty() is always satisfied, so my embedded art should be used. So that part of the code seems to be correct, and not part of the problem here.

That's it for my code review for the night; time to watch some TV before work. But I think the next step is tracing what happens after it has the correct art in master/xbmc/music/infoscanner/MusicInfoScanner.cppSad960-966).
Have you tried using texturecache?
http://forum.kodi.tv/showthread.php?tid=158373
(2017-04-08, 04:42)marktaff Wrote: [ -> ]
(2017-04-07, 12:07)DaveBlake Wrote: [ -> ]If someone can scope out the issue - repeatable problems, features needed etc. , then that could help me when I get to look at it.
I can do that, no problem. Maybe even submit a patch.
Great, what can I do to suck you in Smile

Having something that you want to fix is a great way to find out about how Kodi works (or doesn't), it focuses the mind. There is far more work to do than devs, so contributions from those that have the skills to do so are always welcome. But the review/approveal process can be slow, again not enough devs with time and energy, and hasty changes can easily upset Kodi - it is a chicken and egg situation. I know it gets frustrating for all concerned. I would do my best to support other's efforts, and gladly collaborate.

Quote:I haven't looked at any of the code in over a year, and even then it was just cursory peek, so if you could give me some suggested starting points for peeking through the code, that'd be helpful, Dave.
Seems that you already found the area to start in yourself. I really am vague on thumbs handling, I have never traced it through as too busy with other stuff. It is really hard not to become spread so thinly that I become ineffective.

If you want to keep talking aloud, or have specific questions I will try to engage. I generally know the scanning / scraping process, and the music database, just not the images/texture side which is a little different. I have always just assumed that what was there, when I tripped over it, was right.

Set up IDE, make a Kodi branch and if you post stuff to Git I will look at it there and discuss too. If nothing more then summerising the curent design is useful.
Yeah, I'll probably just keep talking aloud for a spell, as it forces clarity in my own thinking and keeps me on track. :-) I may wind up having to set up a development environment--reading code from the github website is not the most time efficient method. I don't blame the devs for not wanting to break things--something as central as image caching is fraught with risk.

Uatschitchun: I'll check that out. I figured I'd probably need to hack together my own python script to automate targeted deletions in the interim until I can get this fixed in HEAD.
Mark if you have the skills to set up a dev environment then I say do so, and get tracing etc., trying to read from Git is just tedious. There is a learning curve to Kodi, and hands on is really the only way to get into it.

Yes I am unashamedly trying to suck you into Kodi work, but what made Kodi great is enthusiasts contributing their skills. Right now we have millions of users, and yet a very small team of developers streached too thinly. See something you would like to fix or add, then have a go.
(2017-04-09, 11:54)DaveBlake Wrote: [ -> ]Mark if you have the skills to set up a dev environment ...
Yeah, I started on that a bit today; set up a new kodidev user on my main box and started setting up KDE, my shell, and software. I'll probably clone tomorrow and see if I can get through that first compile. But I'm not in a hurry--I still have many other in-work items to juggle.