2014-01-08, 05:15
(2014-01-08, 05:00)rubpa Wrote:Code:./texturecache.py s DSC_0669
016021|4/472d41f3.jpg|0240|0360|0001|2014-01-07 03:47:07|2014-01-07 09:17:07|/mnt/<somepath>/DSC_0669.JPG/transform?size=thumb
016891|f/ffd8f55f.jpg|0720|1080|0001|2014-01-07 13:27:34|2014-01-07 18:57:34|/mnt/<somepath>/DSC_0669.JPG
Matching row ids: 16021 16891
texturecache.py P is not deleting the 1st row but deleting the 2nd row. I checked a few random photos and not always both lines exist. I guess we need to figure out more how xbmc is caching Pictures. I've seen lots of variations in the stored path in the Texture13.db in the last few days.
That's weird, I couldn't get XBMC to cache the original full size picture (the second row in your example above), although I only tested the "slideshow" functionality - maybe an addon has caused the original artwork to be cached, which IMHO is probably not a good thing due to the extra storage requirements, whereas slideshow appears to avoid the cache by accessing the artwork direct.
It shouldn't be a problem to include the original full size artwork paths in the prune processing so that both the preview and full size images are retained in the cache, but is it sensible to keep all those full size images in the cache? Personally I'd want the full size images to be pruned. I guess it can be added as an option, prune.retain.pictures, disabled by default.