Cleaning library ready for Vero V

I’m going to place an order for a Vero V in the next few days, before it arrives I’d like my library to be as clean as possible so I don’t immediately fill it up with artwork cruft.

I have a Pi 4 server running OSMC and MySQL sharing to a Vero 4K+ and several Pi 3’s.

My plan is to use SSH stopmediacentre command, then delete the thumbnails folder and textures13.db on all clients.
Run a library clean for video and music on Pi 4 server.
Install Texture Cache Maintenance Utility on Pi4 and run with prune option as described here…

Copy thumbnails folder and texture13.db to original clients and new Vero V.

Does this sound like the best / most straightforward way to make sure my artwork is as clean as possible?


Why not just not backup/restore the thumbnails folder when you transfer your userdata from your 4K to the V? Is this a particularly old sql database such that there is a lot of entries where there is broken artwork url’s such that it would be a pain to fix a lot of the old shows? Running the library clean is fine; it only removes dead links. The texture cache utility is great but is a bit of effort to figure out the first time. I think if I was setting out to do what you are doing, I would actually just on a PC (because I would rather use a mouse and keyboard for fixes) where I have Kodi attached to the MySQL db remove the thumbnails folder and texturecache13.db and then start Kodi up and scroll through the library looking for missing artwork. When I found it then i, left, enter (at least using the estuary skin) to refresh the metadata. After becoming satisfied my library is in the state I want I would then export to individual files my library. At this point you can fully minimize the cache cruft of any Kodi client by just removing the Thumbnails folder and know that the artwork will be there and what you want. You can copy the thumbs and db together from a PC client to the OSMC clients but honestly I wouldn’t bother.

One thing to note about what I’m suggesting is that what Kodi is exporting for artwork is what is currently cached. If you do this on an OSMC client the default thumbnail resolution is pretty modest. This can be overridden with an advancedsettings.xml but that alone does not change any art that has already been cached. This quirk can be used to your advantage if you wanted to limit the size of the artwork your saving on an export. If you set your cache size to say 1080 and 720 before deleting your thumbnail folder then when Kodi grabs them online anew it will cache big 4k artwork down to the smaller size and that smaller size is what will get saved if you export to individual files.

Hi, thanks for the response.

I don’t have any missing artwork so the video library is pretty much as I want it to appear on the V.

This was more about finding the best way to make sure a load of redundant artwork files don’t get copied over. I’ve used the artwork dump addon to backup all the nfos, artwork, etc so If I ever need to recreate the library it’s all there ready.

I’ll probably do a full SD backup of my server Pi and then give the TCU a whirl.

BTW I have the artwork size set as you suggested in the XML.

Just to clarify a bit about what I was referring to when scrape an item into Kodi it adds the various bits of text metadata to the database which includes file paths to the artwork. It uses those file paths to grab the actual artwork, resizes it if needed, and then stores this cached copy in the Thumbnails folder along with placing a reference to it in the texturecache13.db. If at some point the file path is no longer valid (like something that was scraped with TVDB before they did a overhaul a couple years back for example) you wouldn’t know it until you go to recache anew at which point it can’t because it doesn’t exist and the artwork is then missing.

Maintaining and syncing a cache with an effort to try to keep it minimal is a PITA and IMO not worth the effort. What I think is optimal is to just be able to delete a Thumbnails folder and restart Kodi and that is the end of any maintenance. Kodi should be able to cache on demand and not only will the cache be free of any outdated cached artwork, but the cache can be much smaller if individual clients are not storing artwork for episodes that were never browsed on that client.

My personal Kodi setup consists currently of two Vero V’s, four RPi 4’s, and few installs on PC’s and one on an Android tablet. They are all connected to the same MySQL db’s and file shares. There is no point in which I would ever want to shuffle a cache between those clients or run any cache cleanup program on all of them. I’ve played with a few in the past and it was time and effort that could have been avoided by making sure the database and filesystem is such that clients don’t need maintenance in the first place. So for me this means that all movies and most TV shows have local metadata and artwork. I don’t bother with maintaining local metadata for active TV shows outside of for the show itself so it will have the artwork I want instead of whatever was the default online.

When I need to setup a new Kodi instance I usually just copy the xml files in kodi/userdata/ and call it a day. It is much less painful, and a whole lot quicker than copying the tens of thousands of artwork files my library will have if copied over a clean fully populated Thumbnails folder and its database that texturecache had been run on. The library looks the same both ways with the only drawback being a very small delay the first time Kodi has to cache something.

Understood, I really appreciate your time responding in detail.

Thanks again, happy new year!

1 Like