[Milhouse]

Worked like a charm! Muchas gracias!
I would have expected this to be unneeded when you are already forcing a re-cache/download with the C option.

Indeed, however this is what happens during a force cache "C" option:

Code:

1. Acquire the url of the artwork to be cached by calling Files.PrepareDownload
2. If the url is obtained successfully in step #1, remove the existing artwork from cache (deleting the row and corresponding thumbnail file)
3. Use the url to download the new artwork, creating a new entry in the cache (new row and new thumbnail)

In normal (ie. working circumstances) this sequence acts as a safety net - if the artwork you are attempting to re-cache is no longer available to be cached then texturecache.py won't delete the existing thumbnail you already have in your cache, so at least you'll be left with "something" at the end of the process rather than nothing at all. Users might become rather hacked off if their cache is wiped out because of a temporary networking issue.

However in your case, the db is confused as it thinks it has a thumbnail when it doesn't and this is what causes step #1 to fail so steps #2 and #3 are never attempted. As the db is the main driver when determining if the artwork is "in the cache" or not, once your db is out of sync with respect to the thumbnails folder, "bad things" will start to happen.

It would be possible to add some sort of sanity check to determine if the reason for the failure in step #1 is because the thumbnail file doesn't exist (and if not to then remove the db row and repeat step #1), but this will slow things down and should not in normal circumstances be required. Also, there are several legitimate reasons why step #1 should fail, and querying the Thumbnails folder could become quite an expensive process.

I'll think about it though... I don't want to make it any messier than it already is.

In the meantime, running "Xd" from time to time is probably the best idea, or just when "bad things" start to happen.