/dev/vero-nand/root 100% full, need to resize

Help and Support Vero 4K / Vero 4K +
#1

Thumbnails are the death of me again, filling up my 14GB /dev/vero-nand/root. I went through the procedure to delete and rebuild the thumbnail cache and database, but it filled up again immediately. Seems I have too many movies, TV shows, and albums!

Note all my media is on my Plex server which has about 140TB of storage. Nothing is stored locally on my Vero4K+ and I have no external media beyond a 32GB USB flash drive I use to backups my OSMC config.

My Vero4K+ boots off a 128GB SDCARD, so the simple idea is to expand this paltry partition to something larger. Only problem is…how? cat /etc/fstab says it’s an ext4 partition, so I tried various Windows utilities which claim to be able to resize ext4 partitions. However, these utilities only show one partition, a FAT partition of around 300MB. The rest of the card is listed as “unallocated” which, I suspect, is not correct. Then I tried a live boot of GParted and it showed the same thing.

What am I missing here? How can I get more space for thumbnails?

#2

Vero 4K + can only boot from internal storage.
You could use a symbolic link to expand the local storage used by Kodi; but this won’t be used by default.

/dev/vero-nand/root refers to the internal eMMC (ignore the NAND name – legacy from Vero 2); which means your thumbnails are sitting on the internal storage.

My advice is that you delete them from eMMC, and then we walk you through setting up a symbolic link so you can store thumbs on the card. There may be a performance penalty in doing so, depending on the card.

Edit:

This suggests you’ve taken manual steps to mount the card, and may well have done so over the ~/.kodi directory.

Can you show us the /etc/fstab contents?

Sam

#3

Just shove them on the network and call it a day. I tried this some time back just to test it out and it worked fine. As long as this method isn’t used to share the same folder from more than one client you can ignore any warning you might run across about doing this.

<advancedsettings>
 <pathsubstitution>
  <substitute>
    <from>special://profile/Thumbnails/</from>
    <to>PROTOCOL://YOUR_NETWORK_SHARE/Thumbnails/</to>
  </substitute>
 </pathsubstitution>
</advancedsettings>
3 Likes
#17

Yeah I started to suspect that after I made the post and did more digging around. For some reason I’ve believed all along it booted off the sdcard.

That’s where I’d like to go with this since my media library is, admittedly, gigantic and not going to get any smaller. However, since we’d be using external storage, which would be faster, an sdcard or a USB flash drive? The sdcard is a 128G Samsung EVO with ~100MB/s read/write speeds.

You can disregard that. I was looking at the vero-nand/root by mistake.

I presume what we need to do is partition the sdcard (assuming that’s what you suggest) as ext4 and relocate the Thumbnails directory. What about the Textures13.db file as well? It grows pretty big.

While we’re at it, there are two other “textures13” files in the same directory as Textures13.db file, one with “shm” in the filename and one with “wal” in the filename. What are those files?

#18

I wouldn’t bother redirecting at the OS level as doing it internal to Kodi works just fine. If you prefer to save to a SD card instead of a network location as I suggested above you can do the same path substitution but just point it to a local folder instead. I would not suggest to move the Textures13.db off the eMMC and it should never grow large enough that this should ever become a concern. My library isn’t particularly small and that db is only 17MB.

I’ve never seen or heard of this.

#19

Those are temporary caching files.

1 Like
#20

Interesting. I tried renaming them to see what would happen (I had backups) and Kodi would no longer display any interface at all. I got nothing but a gray screen after the Vero finished booting. Putting everything back fixed it. Very strange, as if they’re caching files I would’ve expected them to be automatically rebuilt if deleted/renamed.

#21

That’s a good idea. I didn’t think of changing the config settings.

Sam, is there any reason why you’d prefer setting up a symlink for Thumbnails as opposed to changing the config file to point to a different location?

Also, regarding the size of the Textures13.db file, mine had grown to about 10GB (yes gigabyte) when I ran out of space. That and the Thumbnails folder took up everything. After deleting the Thumbnails folder and the Textures13.db file, it started to rebuild. The DB file is much, much smaller now. Perhaps the 10GB DB file was corrupted? Full of cruft? I dunno.

BUT…

Now I have another problem: not all the thumbnails are regenerating. Most are, but about 20%-30% are not and I have no idea why. It’s had several days to rebuild and it’s just…stopped. Any suggestions?

#22

10GB sounds like something (I have no clue what) is causing some rather unusual behavior. Even if their wasn’t a space concern I would think that whatever is causing that is also impacting performance.

The thumbnails not showing back up means that the location they were pointing to is no longer present and/or the scraper has changed but the library item has not been refreshed. This can also be caused by using nfo files with art links coming from a scraper different than what Kodi is configured for.

Not to speak for Sam but I think it is a style difference. He spends more time doing OS side stuff so a symlink is a natural thing to do. I’ve done testing with this particular subject and am fairly confident in the effectiveness of the Kodi approach. My testing was actually with a USB connected SSD and a Win SMB share that was sitting on a SSD. The network path seemed to me to work as well if not better, thus my recommend.

#23

While I’ve got your attention, what’s the default compression quality settings for thumbnails? Is it something I can modify? Docs seem to say the default SIZE of thumbnails is 720p and I’m fine with that. However, I could crank up the compression a bit, save some space, and probably not notice the difference.

#24

caching probably isn’t the right word. Write-Ahead Logging

#25

I’m not using nfo files or anything like that. I assume thumbnails are coming from the artwork Plex has downloaded for the media. Plex has thumbnails for everything, and the library had thumbnails for all this same media prior to crashing after running out of space. I’m not sure what you mean by “scraper” in this context.

Anyway suggestions on fixing it?

#26

The Kodi default is 1080 but the Vero has a tweaked system level advancedsettings.xml that lowers this to 720. You can tweak it if you want but I don’t think you are going to gain any significant file space saving. I think your issue has to do with something making thumbs and not cleaning them up. Some plug-in maybe, not sure. This is pretty extreme and not something I remember running across to this extent.

#27

I’m using the Embuary skin so I’m not sure if that gives you any additional information that might be useful. Other than that the only plugins I’m using are PlexKodiConnect.

#28

LOL I actually think I do know what is going on. I migrated my server a couple months ago and found that my Plex userdata was tens of gigs and had something like a million files in it (literally). Digging into why I had set my Plex sources to bring in extra info (I don’t remember the exact name and details) and by turning that off, deleting Plex’s cache files, and then refreshing in Plex to recreate this data, I was able to get a sensible install to migrate. I would suspect that you also have this extra art enabled in Plex and it is then bringing it up in the Kodi client and not cleaning up after itself.

#29

Sounds like your Plex was Linux based whereas mine is Windows Server 2019, so I’m not sure where to find the equivalent “userdata”. I’ll dig around in Plex and look for artwork caches or anything that looks similar. It’s still confusing though. I can’t understand why thumbnails that pulled fine before I deleted Textures13.db/Thumbnails won’t pull now. Nothing’s changed on the Plex side so, in my head, it should just re-populate on Kodi. Only it doesn’t.

#30

Nope, Win10. I don’t really use it with Kodi though other than the occasional testing to try to figure out an issue someone asks about here. In my house I use a MySQL Kodi setup and Plex is just for my daughter to have access to my media at her house. The following I think describes the issue I had and it was video preview thumbs causing much of the bloat I think…

The reason why you didn’t have an issue before you deleted texturecache13 is because it wasn’t having to look for them. Kodi stores a link to a piece of art, this then gets used to generate a thumb and that thumb gets pointed to in texturecache13. If you delete the thumb, or the database that is referencing it, then Kodi then going back to the path of the art that is stored in the video db. If the path is not valid then you don’t get art until you update the scraping info for the library entry. I’m not all that familiar with the inner workings of PKC but I would guess that it is grabbing the art from Plex and older links probably went dead when Plex changed its default scrapers some time back.