[RELEASE] Texture Cache Maintenance utility
(2013-07-04, 05:13)MilhouseVH Wrote:
(2013-07-04, 05:05)wishie Wrote: Here is a log file (thankfully it was still in my clipboard)

https://dl.dropboxusercontent.com/u/1373...ecache.log

The folder "Doghouse" was empty (so were some others, but this was the first one the script encountered

Many thanks for that, most odd that I couldn't reproduce it - for an empty folder I get a "files" item with a "null" value (ie. no files) but you have a response that doesn't include the "files" item at all. Either way it shouldn't be a problem with the next version of the script.

(2013-07-04, 05:05)wishie Wrote: I will try your other command for multipart movies shortly.

Actually no need to worry about that - I mocked up a couple of multi-part files and scraped them in to my library and can see they are being handled as stacked files which is now supported in the new version of the script. Thanks for reporting the problem.

Version 0.8.6 (04/07/2013)
  • Fix: When looking for `missing` (unscraped) media items, allow for empty remote folders (no files)
  • Add: Include `file` as a default field when dumping (`j`/`jd`/`J`/`Jd`) media library items
  • Add: Stacked/multi-part movie support to `missing` and `qa`/`qax` options
  • Add: Group similar `prune` items together, by sorting results on url


Should searching for empty folders be an option?
In my case, I was glad I could find them, and therefore remove them.

(2013-07-04, 05:14)HueyHq Wrote: Wow - thanks for replying so quickly!
(2013-07-04, 04:49)MilhouseVH Wrote: ...however Textures13.db remains as a local SQLite database on each and every client because it manages the local artwork cache that is unique to each client.
You make particular reference to client DBs, so what happens on the server machine?

The reason I ask is because, against the trend, I use path substitution for the Thumbnails folder. In Frodo.
(I know, I know, I don't get the performance, but man, does it make maintenance sooo much easier! Each new Pi on my network gets the same advancedsettings.xml thrown on an OpenELEC install - no fuss, no stress, and it just works! AFAIK, nothing pertaining to the media is stored on the Pi - it all comes from the server.)

If access is done via JSON, will Textures13.db still be relevant in my case?

I'm curious to see if I delete Textures13.db, whether or not XBMC will recreate it!


Ive just spent nearly a day undoing the mess that a shared Thumbnails did caused. I used to use path sub for it too, thinking it was a good idea, even though I was told otherwise.
The performance on the clients suffer (especially if Pi/ATV2/Android devices), network load increases, etc etc.. Its simply not worth it.

My understanding now is, if you remove the Textures.db and path sub from the clients, they will automatically download the artwork (based from the URLs stored in the video library) store them in its own Thumbnails cache and build Textures db locally with optimised images. This may be a pain to start with, but will be a very minimal (and automated thing) afterwards.

You end up with less network traffic, and faster client performance.

I still use MySQL for my video and music libraries, but artwork should be unique for each client. I guess there is no harm having a shared thumbnail cache for 2 Pi's or 2 ATV2's or something, but I still wouldn't do it.
Reply


Messages In This Thread
RE: [RELEASE] Texture Cache Maintenance utility - by wishie - 2013-07-04, 05:17
Crash on Gotham on OS X - by desepticon - 2014-05-29, 17:57
Cleaning - by AleisterHH - 2018-05-28, 22:03
RE: Cleaning - by Milhouse - 2018-05-28, 22:16
qax genre not updated - by Just-Me_A-User - 2018-06-12, 22:06
RE: qax genre not updated - by Milhouse - 2018-06-12, 23:40
Logout Mark Read Team Forum Stats Members Help
[RELEASE] Texture Cache Maintenance utility17