Kodi Community Forum

I am running a headless KODI instance on my NAS (with limited storage) and don't see any need for it to cache images when scanning in media.

I am using a web-interface for initiating scans etc, but it's text only (for faster browsing via VPN).

And I'm pretty sure that all the other instances of KODI download the media themselves via the URLs in the MySQL DB.

I am thinking I could symbolic link the thumbs directory to /dev/null - but think this maybe issues due to missing folder heirachy.
Or, I could path substitute thumbnails to /tmp/kodi directory
and or, I could use a cron job to clear out the thumbs directory each night.

Will clearing out this directory cause issues?
Should I also remove the textures DB at the same time?

Or, is their maybe a settings somewhere to disable all thumbs downloading?

I think a cron job for the below seems the safest to me (and not touch the textures db)

find ~/.kodi/userdata/Thumbnails -type f -iname \*.jpg -delete

(2016-10-18, 01:25)matthuisman Wrote: [ -> ]Will clearing out this directory cause issues?
Should I also remove the textures DB at the same time?

Yes and yes.

The database and content of the folder are linked. Change/delete the contents of one without the other and you'll have problems.

(2016-10-18, 01:25)matthuisman Wrote: [ -> ]Or, is their maybe a settings somewhere to disable all thumbs downloading?

No. In addition to caching, textures are optimised for faster display which usually involves resizing and even format conversion. Disabling the cache is therefore not a supported option. Your usage of Kodi is an extremely niche use-case.

(2016-10-18, 01:25)matthuisman Wrote: [ -> ]I think a cron job for the below seems the safest to me (and not touch the textures db)

find ~/.kodi/userdata/Thumbnails -type f -iname \*.jpg -delete

Not safe at all.

If you want to remove items from your cache, see the script in my sig. Try the purge option.

thanks for the tips

As the images are never pulled from this instance, it would be great to just stop KODI downloading the images at all.

This would also make scraping quicker.

As it never will try to show images (headless), then I don't see it crashing as it will never try to get an image.

Looking at your script, I can't seem to see an option to delete everything.

Oh, I think below may work
./texturecache.py purge all


I tried doing a ln -s to /dev/null on the thumbs folder.
Start up error in log about not creating the heirachy folders (a,b,c etc), but then scans in new media fine
And no images downloaded
This saves writes to my emmc card, maybe make the scanning quicker, and saves on storage space.

Also checked the MySQL DB, and the image URLS are still being scraped so the client instances will D/L them fine.
Then checked the Textures DB and it is remaining empty as well. Perfect!

should work, and delete all cached artwork.

Alternatively, shut down kodi, delete Textures13.db and the Thumbails folder, then restart Kodi.

As for sym linking to /dev/null, it's likely Kodi is downloading the remote artwork but then has nowhere to store the cached version, so it's unlikely you're saving any bandwidth or making the scan any quicker. Your kodi log will also be full of cache-related errors. But if you're happy, great.

I can't see any errors in the log except for the initial ones.
I also can't see any tmp files anywhere of the artwork.
If it's still getting them in memory, that's fine - as it's not writing to my emmc.

I'm hoping they have code that if it fails to create the thumbs on boot / then it won't try to D/L artwork.
I might dig into the source and have a look at the logic.

Pretty happy with my updates now.
10:21:37 T:2903503792 NOTICE: VideoInfoScanner: Starting scan ..
10:21:41 T:2903503792 NOTICE: VideoInfoScanner: Finished scan. Scanning for video info took 00:04

That's when no new media and also without fasthash (as i'm using AUFS which doesn't update folder modified dates reliably)
That's checking 2.5TB of media.
Using path subs from SMB path to local path makes it much faster - and the media still scanned into DB with SMB paths for other KODI instances.

When I was updating via my shield across the gigabit network, updating library would take much longer.

Clean is even quicker
10:18:39 T:3022782464 NOTICE: CleanDatabase: Starting videodatabase cleanup ..
10:18:40 T:3022782464 NOTICE: CleanDatabase: Cleaning videodatabase done. Operation took 00:01

I'm using USB3.0 drives formatted to ext4 and AUFS to "merge" them into a single directory.

Actually, as I'm building KODI and already applying a few patches (headless etc), I could just patch the code not to cache.

Could I simply add return "" at the start of std:tring CTextureCache::CacheImage function?
(https://github.com/xbmc/xbmc/blob/8d4a5b...e.cpp#L133)

Pretty much just simulate an empty URL.

Update 1:
Hmm. with that change, it still cached.
I see a few other functions (I suspect backgroundcache).

So, now trying the below 'shotgun method' patch...:
http://pastebin.com/raw/BR7Z1RLZ

Update 2:
That worked.
All URLs still in shared DB (art table, actor art_url, movie c08 thumb info etc)
But, no files in thumb directory.
And it seems to have sped up scraping
Also did a DB export and the NFO files are correct (all image links for actors, post, fanart)
Not sure what an export with images would do, but I don't use that so not worried.