Attention: Thumbnail cache rewrite's unintended consequences

The resizing code is already in (no image other than fanart will be cached larger than 720p now, fanart defaults to allowing 1080p if the image is 1080p, else drops down to normal image size). You can reduce both if you wish via the <imageres> and <fanartres> tags in advancedsettings.xml (will update the wiki in a bit).

Cheers,
Jonathan

Thanks for the info. I'll give it a test.

No album covers for me. Artist images are fine. If I re-add with "get thumb" it's fine from then on. I tried scrolling down the list to try and activate the cache to no effect.

Read my posts

You need a rescan of all tag data to get thumbs. I'll be adding a prompt for this over the weekend.

Sorry, I was put off by the artist images working and I must have imagined that browsing over the albums was going to reload them. I must have been thinking the comments on PR were happening.

Auto-rescan from the UI: https://github.com/xbmc/xbmc/pull/1124

Not completely sure about it - in particular, the user can choose to stop the rescan (or never start it and be constantly nagged).

Alternatives are:
1. Invalidate all the paths in the db, so that next scan it'll rescan anyway. Problem is if online lookups are done, then any artists/albums not found will be re-checked even though they don't necessarily need to be (slow).
2. Add ability to rescan-all to the music library settings in some way - this would take the normal online lookup setting I guess.
3. Add ability to rescan a source from the context (not sure this makes sense to be honest - XBMC's music library automatically detects if the user changes any tags).

Thoughts?

Cheers,
Jonathan

Jonathan - Wondering if you have any suggestions on this issue.

Setup is MySQL with movies in separate folder for each movie.
Thumbs and fanart are downloaded along with movie and are named folder.jpg and fanart.jpg.
I'm very particular about my thumbs and like them to be clean of any extra text in the image. If a folder.jpg is downloaded that I don't like, I'll usually just open up gimp and modify the file to my liking.
The problem is that since the file name stays the same, it doesn't refresh the thumb to use the newly edited image.
The only solutions I've found to get the updated thumb to show are 1) rename the file to something other than folder.jpg (such as movie.tbn) or 2) delete the textures13.db and Thumbnail folders.

Is there some way that the file modification can trigger the db to point to the newly updated image instead of having to do one of the 2 options above?

Video showing the issue here -

It will automatically refresh after 24 hours minimum. The basic flow is as follows:

1. When the image is loaded (i.e. when it pops up on screen) XBMC checks to see whether a 24 hour timer has passed since the last check. This occurs for anything other than http:// URLs.
2. Assuming the 24 hour timer is passed, it then does a check of the original file to see if it has changed - in particular it compares the modified time of the file and the file size.
3. If the hash is different, we fire off a re-cache job.
4. Next time the image is loaded, it'll use the re-cached version.

Cheers,
Jonathan

I really like this new approach for the textures. I do however wonder what will happen if I delete a cached file. Will XBMC detect the file is missing an try to re-fetch it?

The Texture database is king, so if the texture database thinks it has the file it will use it regardless of whether the file actually exists.