[SiliconKid]

After removing a video source from the library and opting to remove all items and clean the library, I've noticed that one of the copies of the .tbn thumbnail image in one of the subfolders under

\AppData\Roaming\XBMC\userdata\Thumbnails\Video

is not getting deleted.

I'm not actually sure why 2 copies of the thumbnail, that appear to be identical, are being created in 2 different sub folders in the first place, but 1 of them is definitely being left behind after a remove and clean.

It's the cover image that this all applies to. Fanart images seem to be cleared out correctly.

To be specific, the same image is being cached as:

a32447bd.tbn and dbc07c2f.tbn

They are identical in every respect, specifically:

Image dimensions: 836 x 1253

File Size: 187 010

Why does it cache the same cover image twice in 2 different sub folders in the cache?

[SiliconKid]

Following up, I've just done a remove again and it left the dbc07c2f.tbn file behind in the sub folder named "d".

All other cached artwork was automatically removed as expected.

[SiliconKid]

Update:

Using the C# Hashing routine I found on your Wiki I hooked up a C# console app quickly and generated a few hashes myself to compare.

I get the SAME file name as one of the tbn cover images being stored in the cache if I pass the hashing algorithm the full path and file name of the movie file, as expected.

But as yet, I cannot explain where that 2nd copy of the same image is coming from or how that 2nd hash code is being generated, based on what.

[SiliconKid]

I turned Debug logging mode on and in the log I see this:

23:46:57 T:7436 INFO: Caching image from: V:\XBMC Test\Elektra\fanart.jpg to special://masterprofile/Thumbnails/Video/Fanart/a32447bd.tbn
23:46:57 T:7436 INFO: Caching image from: V:\XBMC Test\Elektra\Folder.jpg to special://masterprofile/Thumbnails/Video/a/a32447bd.tbn with width 1024 and height 1024

Which matches one of the hash codes.

But there is NO entry anywhere in the log that refers to the creation of the other, identical tbn file with the 2nd different hash code.

[SiliconKid]

Any ideas on this devs ?

I'm concerned that thumbnails are being left behind in the cache after completely removing a source from the library and cleaning up.

Effectively that means that the thumbnail in question is getting orphaned somehow. As explained above it's unclear where this orphaned thumbnail comes from in the first place or how its Hash is derived, but I'm concerned that it could result in rogue thumbnails that affect the UI somehow.

If a thumbnail is put into the cache as the result of adding a specific source and I then remove that source and tell XBMC to clean all associated items out of the library, I expect ALL thumbnails etc. related to that source to be completely removed.

[jmarshall]

My guess is the 2nd thumb is coming from the file rather than the folder (or vice-versa).

A google search will reveal quite a bit about this stuff, eg http://forum.xbmc.org/showthread.php?tid=129508

For videos, this is all taken care of here: https://github.com/xbmc/xbmc/pull/919

Cheers,
Jonathan

[SiliconKid]

Unfortunately, it's not. I've done that experiment already. I've generated Hash codes using various combinations of things and none of those combinations result in that 2nd Hash code.

And yet, that cached image is IDENTICAL to the one that is generated off of the movie file with full path.

That's only half of the issue though, the other half is the fact that it doesn't get cleaned up, which is clearly not right.

I've already read the articles you refer to above and I don't post unless I've done my homework first. I'm perfectly capable of Googling for information, I spend half of my professional life doing exactly that. The problem is, in this case, the results I'm getting aren't clarifying my specific issue, hence my need to communicate with developers like yourself who know what's going on internally.

Having said all that, you have mentioned previously that this whole caching story is changing and the thumbnailing system is getting revised, in which case I'm not sure it's worth spending too much time trying to understand this issue?

As always, I do appreciate your input and your prompt responses.

[jmarshall]

Correct - in about a week that will be pulled in, essentially negating any need to explain or attempt to understand the current system.

The new system has everything in the database, so it's much easier to clean stuff out (no need to know the hash formula for example). Further, all thumbs are actually stored using their original URLs, so no need for duplicates (except for different sizing). Lots of other neat stuff as well will come in time.

The current system caches images based on video, folder (and other random things that are quite a bit sillier than those), which means duplicates of the same thing (different hashes) and extremely difficult to attempt to clean everything up.

In your current case, it'll almost certainly be a particular combination of file and folder, and it should be in the log (the cache functions all log afaik).

I like to leave other links/suggest searches because unfortunately many folk don't bother, and I've answered stuff about this many, many times - no offense intended

Cheers,
Jonathan

[SiliconKid]

Excellent, I look forward to those enhancements.

No offense was taken, I assure you, I'm just direct and blunt and like to get to the point.

And again, the input of technical people like yourselves is extremely valuable to a forum like this so I thank you again for that.