[braz]

Something I've noticed is that when selecting a different artist thumb from the info dialog, Kodi keeps reverting back to the old cached image. It would be nice if selecting new artwork would stick without further effort. Is there a way to overwrite the cached image when selecting a new thumb?

The only way I've found to fix this is to run texturecache.py after changing artwork through the gui.

[braz]

Hmm, just tried changing some more artists thumbs after having run texturecache.py to recache, and now the new thumbs seem to be sticking without having to do anything else.

[Karellen]

Yep, that is a known.

Give it 24 hours and you will find the image will have changed on its own. (assuming you leave kodi running)

Have a read here... https://forum.kodi.tv/showthread.php?tid=328578

[braz]

Thanks @Karellen, still seems to me that recaching the single image when it is replaced via the gui would be better than waiting 24 hours.

[DaveBlake]

...seems to me that recaching the single image when it is replaced via the gui would be better than waiting 24 hours.

 I agree. I also have to say that the "wait 24 hours and magically fixed" sounds like superstition to me, does that really work? If it does then can someone show me the code that does it. The other thread also suggests that the current "change resistent" behaviour is by design, and I have doubts about that too. Yes caching is by design, but there are also obvious attempts in the code to update that for individual items when new art is manually selected. However from user experience these don't always work especially for local art.

Now changes to artist art selection are in my recent info dialog PR and test build, and I may have managed to ensure that local images do get recached. But forgive me if not, and I suspect that recent testing is still showing a caching issue, at least I am aware of what I think of as a glitch and trying to improve behaviour.

[braz]

...seems to me that recaching the single image when it is replaced via the gui would be better than waiting 24 hours.

 I agree. I also have to say that the "wait 24 hours and magically fixed" sounds like superstition to me, does that really work? If it does then can someone show me the code that does it. The other thread also suggests that the current "change resistent" behaviour is by design, and I have doubts about that too. Yes caching is by design, but there are also obvious attempts in the code to update that for individual items when new art is manually selected. However from user experience these don't always work especially for local art.

Now changes to artist art selection are in my recent info dialog PR and test build, and I may have managed to ensure that local images do get recached. But forgive me if not, and I suspect that recent testing is still showing a caching issue, at least I am aware of what I think of as a glitch and trying to improve behaviour. 

 Thanks @DaveBlake, good to know this is a known "quirk." At least we have the Texture Cache Maintenance Utility, it seems to be the only surefire way to cache images in my experience. In the past I used to have to delete entries from the texture db to force them to refresh.

[DaveBlake]

I understand more about the magic 24 hours now

When local files (but not images that have been fetched from online sources) are cached they also get a last checked timestamp. The background loader that populates the screen with images as you navigate always checks if the image is cached and when it was last checked. If more than a day has passed since it was last checked it gets checked for changes and recached. So the first time you change local art e.g. replacing a folder.jpg file, you should see it immediately but if you change it again then you won't see the results until at least 24 hours later.

It would be horribly slow to check if local files have changed every time they are used, so users directly changing the files on their drive just have to wait for the cache to automatically catch-up if that image had already been (re)cached that day (or run a utility that cleans out the texture cache). But there is no reason not to reset the cache check for individual items that are manually changed via Kodi, it just has not been done (succesfully) yet.

[DaveBlake]

Also having a play with this I notice how frustrating it is having the caching apply to the thumbs of local image files when browsing to select art manually. All images that appear on the GUI get cached, this applies to browsing folders looking for images, it caches a small thumb and the image. So if you notice folder.jpg isn't what you want and replace it on your hard drive, you won't be able to see that you have done that on the selection screen, let alone on the artist/albun/song that you are selecting art for.

[braz]

In addition to this, I've found that if I browse to item folder and manually select the updated folder.jpg, it will display in Kodi initially but then revert back to the old cached image (usually after a skin reload or editing other artwork).

[scott967]

The main problem I have had, is sometimes I have an artist with no art.  I hunt around and find a folder.jpg and fanart.jpg that I place in the artist info folder along with artist.nfo file.  In Kodi I do a "refresh" on the artist and typically I see the art is displayed in the info dialog but not always shown in the music window.  I have gotten into the habit of using the get art (actually get thumb/fanart) button and selecting the "local image" for both.  That seems to always work.

I have had the problem of updating album art via a new folder.jpg in the library folder and it doesn't seem to "take" (displayed image doesn't show a change), even with a get art (get thumb) from info dialog.

scott s.
.

[Karellen]

One of the upsides of the image caching, is that you can simply, via the OS browser, replace local artwork with new local artwork, and not do a thing in Kodi. eg, replace poster.jpg with a new poster.jpg.

Once Kodi runs the image hash check, the artwork will be auto updated and visible in Kodi, without having to fiddle around with Get Thumb, Get Fanart or Choose Art settings in Kodi.

Depending on when the last hash check was performed, it will auto-update when you navigate title, or sometime within 24 hours.

[Powerhouse]

I understand the 24 hour thing, but something as easy as changing a Thumb, Fanart, Poster, etc, should be instant. If this can't be changed, then perhaps have a dialog pop up that says, this could take 24+ hours to take affect.

[braz]

This is especially frustrating from a user perspective when the new art shows up in the info dialog but not the library as @scott967 mentioned, or is shown for a short while only to revert to the cached image. Even with caching every 24 hours, there's got to be a better way to handle the case where new art is selected through the GUI.

[DaveBlake]

Guys I am listening, but I just hope I'm not stiring up interest and expectation that I am unable to satisfy.

...something as easy as changing a Thumb, Fanart, Poster, etc, should be instant.

[my bold] @Powerhouse I know it is unintended, but after a day of hair tearing the last thing a dev needs to hear it how easy it should be

@Karellen is right, directly replace an image file on your hard drive and Kodi will automatically catchup by a day later. Kind to think of that as an upside, +1 for positive attitude, but using Kodi to manage local art the caching clearly makes it tricky.
 

The main problem I have had, is sometimes I have an artist with no art. I hunt around and find a folder.jpg and fanart.jpg that I place in the artist info folder along with artist.nfo file. In Kodi I do a "refresh" on the artist and typically I see the art is displayed in the info dialog but not always shown in the music window.

I think I have fixed that issue with my music info dialog PR. I'm just tweeking some other issues, but will have a new test build up soon (I hope).
 

I have had the problem of updating album art via a new folder.jpg in the library folder and it doesn't seem to "take" (displayed image doesn't show a change), even with a get art (get thumb) from info dialog.

That is the caching delay, is applies to any image that you have previously browsed or used. I would like to be able to turn image caching off when browsing local images for selection. It would reduce cache bloat and solve the frustrating "image not take" experiences, but I have not had the "ah ha" moment for implementing that. A "refresh thumbs" button on the image selection dialog may be a simpler alternative.
 

I've found that if I browse to item folder and manually select the updated folder.jpg, it will display in Kodi initially but then revert back to the old cached image (usually after a skin reload or editing other artwork).

I'm not sure I have repeated exactly that, then I have already started trying changes, maybe I fixed that bit eh? I suspect it is because during local art selection there are two forms of the images get cached:
a) a thumb of the image e.g. as "image://C%3a%5cTestArt%5musicart05.jpg/transform?size=thumb"
b) the image itself (once selected) e.g. as "C:\TestArt\musicart05.jpg2
Browsing creates lots of cached records like a), only when picked does it make b), so change the image file between initial browsing (any time in last 24 hours) and final selection and you get the odd mismatch.

There is also the fact that any given path+filename results in a specific cached file name, so if for some reason the texture db entry is deleted but the cached file left in userdata/thumbnails, then this old cached image will reappear next time that path+filename combination is cached.

Understanding the issue is the first step to solving it, but fundamentally Kodi was not designed to be a file manager for dynamic local image files. The caching, which is ideal for faster navigation of media files with static art, has undesireable side effects. I will see what I can do, but no promises as it is far from easy.

[Powerhouse]

Guys I am listening, but I just hope I'm not stiring up interest and expectation that I am unable to satisfy.

...something as easy as changing a Thumb, Fanart, Poster, etc, should be instant.

[my bold] @Powerhouse I know it is unintended, but after a day of hair tearing the last thing a dev needs to hear it how easy it should be

@Karellen is right, directly replace an image file on your hard drive and Kodi will automatically catchup by a day later. Kind to think of that as an upside, +1 for positive attitude, but using Kodi to manage local art the caching clearly makes it tricky.

Don't get me wrong, I didn't say fixing it would be easy, I said that it is easy to change them (from a user perspective). As has been pointed out, you can replace the images in your Music Artist folder, or use the Context Menu to select new Artwork. Either is very easy to do for the user.

Now fixing how the caching in Kodi works, that will require additional work (read, NOT Easy for the Devs).

As I've been going through all my Music Artwork at the moment, waiting 24 hours isn't that bad. Also, If I wanted, I could just remove my Music Library, and then Re-add it, and this fixes all the issues mentioned. The Up side to doing it this way, it only takes about 2 hours for my Library to be re-moved and then re-added to Kodi (and I have a very large collection).