[Milhouse]

I intended to definitely remove unnecessary thumbnails but not the thumbnails of my "Pictures". Anyway, it's not a big problem since it gets regenerated locally when I visit the folder again even without any network.

I'm working on a version that will not prune your picture and folder previews. Your pictures (ie. those you view, eg. full screen in a slideshow etc.) are never cached. And unfortunately it's not possible to pre-cache the previews - it looks like it's another one of those situations where the GUI does something special which can't be replicated with JSON. I should have an update shortly.

After the P command, I ran texturecache.py R and got this:

Code:

Found 13,199 orphaned files for 1,326 database files.

This is far too many orphaned files for this number of
database files - more than 5% - and something may be wrong.

P would fail to delete the files if there is a permission problem preventing file deletion. Assuming that isn't the case, another possibility is that the orphaned files already existed before you ran the P command and may have accumulated over the previous year or so. Orphaned files often result whenever XBMC is upgraded to a new major version (eg. Dharma to Frodo or Gotham), as the thumbnail files from the old system are left lying around.

I guess P command just cleaned the database rows and now the R command would remove the actual thumbnail file referenced in these deleted rows. Can you confirm?

Only if there is a permission problem when deleting from the Thumbnails folder. But yes, the R command will clean up the left over files and get things back in to shape. However if P couldn't delete the files, then it's unlikely that R will either.

Also, the actual scanning & caching is done by xbmc when I view the pictures. I'm confused by "...then it can be scanned... and cached"

I had hoped it would be possible to cache the artwork previews, but it turns out that isn't supported by JSON, and although it is possible to cache the full resolution pictures there's absolutely no point in doing so as they're always displayed directly from source and not via the cache (which is just as well, otherwise the storage requirements for the cache would balloon). So the best I can do with this script is simply to not prune your previews, assuming most people want to keep the previews. It's not much, but it might help.

And if you do want to delete the previews, there'll be an option to set. Or there is the "purge" option which takes one or more string patterns and removes items (database rows and files) from the cache.

and also your signature states "Preload your texture cache for optimal UI performance". Are these related? Does this utility improve xbmc performance by doing something more at every boot? Can you explain?

As you browse around the XBMC GUI, images will be loaded into the cache which involves resizing and format conversion etc. The images you see on the screen are loaded from the cache (except for full size pictures, which load directly from the source). On low power platforms (such as the Raspberry Pi) the extra work populating the cache can be quite noticeable, so pre-loading the cache ensures that when you browse the GUI there are no stutters or delays as all your artwork is already cached.