[Milhouse]

can picons be pre-cached?

What are picons?

Edit: Turns out these are TV channel logos. Whether they can be cached depends on a few things, mainly: 1) Does XBMC support picons? 2) Is the location of the original picon artwork "discoverable", ie. available via the "PVR.GetChannels" method?

Try: "./texturecache.py jd pvr.tv" (or pvr.radio) and see what artwork is available.

Maybe some additional background on picons.

The "C" command showed an error in the summary. I believe I provided debug logging of this earlier, but it's very easy to duplicate. I rebooted and tried the commands again with no change.

I think there's a small bug here. Let me know if I can add anything further.

Ah yes.

When downloading (caching) artwork, it's a 2 step process - obtain the "real" url of the artwork to be cached by passing the current url to the "Files.PrepareDownload" JSON method, then actually caching the artwork with an http request to the XBMC webserver using this real url.

When using the "C" method, the database row is deleted only once the real url is obtained from "Files.PrepareDownload", so if this call fails - which presumably is the case for TMZ - then the database row is not removed as it won't be possible to (re-)cache this artwork, so it's better to leave the user with what they already have. The row would however be removed when using "Xd" as this option doesn't care about "Files.PrepareDownload".

The reason the "Files.PrepareDownload" call fails is because the original artwork is no longer available or accessible. Removing the database row before the call to "Files.PrepareDownload" is not an automatic option (however, see later) as the already cached thumbnail may be perfectly fine - you might have been "freshening" other artwork for the same movie/tvshow/addon, and you'd be left with less artwork than you had before.

In the case of TMZ, what you are experiencing is a pretty rare corner case (remote artwork unavailable, database row is present but the thumbnail missing), which would be fixed by running "Xd".

However, there is one other option available to you - pre-deletion.

Enable with "@Download.predelete=yes" (default value is "auto") and this will delete all of the artwork to be re-cached before any attempt is made to download, rather than deleting artwork during each download thread (and then only if the artwork is accessible). Enabling this option will of course delete cached artwork that cannot then be re-cached.

The pre-delete option exists to prevent a remote system with direct SQLite access - eg. a PC with Databases and Thumbnails mounted belonging to a remote XBMC client, eg. a Raspberry Pi - from making multiple overlapping db deletions (inside each download thread) which could potentially lead to SQLite corruption.

Pre-deletion is now unnecessary following the addition of the JSON Textures API in Gotham which avoids any potential SQLite corruption, but is something that would still be used by older clients that don't support the Textures API. It may also be useful in your case even though your client doesn't technically require it.

So either run "Xd" from time to time as part of a standard maintenance routine, or try enabling pre-deletion (though this has a downside, as explained above). Generally speaking, you shouldn't need to use either option on a regular basis - if you do, that would suggest a problem elsewhere.