[steve1977]

No errors, but it didn't cache anything. I'd assume that all files are considered cached already. "C" works but "c" doesn't cache anything.

[Milhouse]

No errors, but it didn't cache anything. I'd assume that all files are considered cached already. "C" works but "c" doesn't cache anything.

"nc" will show what needs to be cached. "C" of course removes items from the cache before re-caching them.

[steve1977]

Thanks. I understand the difference between c and C. The weird thing is that nothing gets cached with the option "c". However, there is clearly a need for caching on the MrMC/ATV as artwork loads very slowly. When applying the option "C", the caching is happening. But, that's not a sustainable approach.

Where does texturecache draw the information from what needs to be cached?

[Milhouse]

Where does texturecache draw the information from what needs to be cached?

The same place as "c" - it compares the artwork urls in your media library (MyVideos/MyMusic) against the cached urls in the devices Texture Cache (TexturesXX.db) and anything in the former that isn't in the latter will need to be cached (and would be reported by "nc").

If "c" is not caching anything then this would imply that "nc" would also report that nothing needed to be cached.

If however you're sure that artwork items are not in the device Texture Cache this would suggest a problem somewhere. I'm not familiar with MrMC releases but I doubt these releases have modified the artwork caching process.

You can confirm if an artwork item is present in the Texture Cache by searching for a partial url with the "s" option (you can view media library urls using the "jd" option) - if you don't see your artwork listed after using the "s" option then it's safe to say the artwork is not present in the Texture Cache database (and should therefore be listed by "nc", and cached with "c").

However if the artwork is listed by "s" but viewing the artwork in the GUI is still slow (making you think the artwork is not cached) then you should - if possible - run the "Xd" and "R" options as it may be that the contents of TexturesXX.db and the contents of the Thumbnails folder are out of sync (unfortunately the "Xd" and "R" options must be run directly on the device which may be impossible if the device doesn't support Python, in which case "C" is the only choice).

[steve1977]

Thanks. Let me look into this.

I do have one other suspicion besides MrMC potentially being different. I initially had not added a "video library source" and never run "update library" or "scan new content" on the MrMC device. I always do this on one "master device" and MrMC only accesses mysql. Could this be an issue?

[Milhouse]

If you're using MySQL then in MrMC you should only need to add sources.xml/passwords.xml, restart Kodi, then cache your artwork - no need to scan or update library.

[steve1977]

Can i use the script to wipe the thumbnail folder and delete texture file? i don’t think i can do this on mrmc as i cannot ssh into my apple tv.

[Milhouse]

Can i use the script to wipe the thumbnail folder and delete texture file? i don’t think i can do this on mrmc as i cannot ssh into my apple tv.

No - the script can only use JSON APIs when the client is remote and there's no such API to wipe the texture cache.

[steve1977]

mmh... any other idea how to delete it? it may fill up over time the whole ATV. maybe through file manager in kodi? i know this actually is a mrmc question, but still appreciate your thoughts. thanks!

[Milhouse]

You might be able to do it through the Kodi File Manager if you add an appropriate source, but removing the Textures13.db and Thumbnails from within a running system could be interesting!

[steve1977]

the texture.db shouldn’t be the issue. it’s a small file. the thumbnail folder is huge. let me try whether i can delete folders. i’ve done this before on LE via SSH and was not an issue.

[steve1977]

I haven't deleted any of the folders yet, but this is really weird. I looked again in the command prompst for c and C and also ran nc.

nc and c confirm that there is the need to cache artwork. It lists hundreds missing and need to cache. It then actually starts caching and does not give an error message. However, caching is very quick and no actual caching happens. See one line of an example below. It's done after 1-2 minutes with 16,000 artworks. While I wish that I had such fast Internet connection, this is not the case and nothing is being cached. For whatever reasons, C works, but c does not. nc lists all missing artwork.

Caching artwork: 14017 items remaining of 16193 (qs: 0, qm: 14010), 0 errors, 2 threads active (71.80 downloads per second, ETA: 00:02:22).

Any thoughts? Is there an error log I can consult?

[Milhouse]

You can enable texturecache.py logging by adding @logfile=tc.log - run "c" for a small selection of movies that have artwork which needs to be cached then upload the log somewhere and I'll take a look. The actual downloading and caching is performed by Kodi so enabling debug logging in Kodi might reveal what Kodi is doing, but it sounds like Kodi is not actually downloading (and therefore caching) the artwork it is being asked to download, which is odd.

[steve1977]

Will try tonight. Thanks. It may be that MrMC changed something that broke this functionality. The weird thing is that C appears to work (at least it is taking forever), so - if something is broken - it is specific to c.

[steve1977]

It's a bit difficult to post the log as it immediately balloons to 30MB. 

Let me share some snippets, which may give you some indication what is going wrong with the "c" tag. It claims it downloads, but in reality nothing happens:

https://pastebin.com/UurcPXbd