[Martijn]

The high load is because the images get converted. If it's done, cpu load is back to normal and everything is smooth but since XBMC is converting the images only if they get displayed, it can last days or weeks until everything is converted... also there are new images to convert all the time if you use add-ons like youtube. But the main problem are big fanart images for those I would like to have an option to exclude them from being cached & converted.

Correct me if i'm wong but isn't the high CPU load a problem on low power sytems? I can imagine an Ion has less capacity in comparison to an Intel Core2.
Another option would be to pre-convert them when the system is idle.
I found some program you need to run from a batch script but i don't think that's the ideal way.
IMO both cases could be examined. Preventing high load when brwosing and option to disable cashing. Espicially for youtube for example cause wou will probably only use/see them once. Fanart is a returning item i think.

[Martijn]

I know cashing speeds things up locally. However xbmc also supports placing the thumbnails folder on a remote place using the substitute function in AS.xml

So doesn't this defy the point using the cashing to speed up things?
First you cash a file because it's on a remote location and then you use supstitue to place it back at a remote location. That's twice the storage usage for no speed gain.

It even gets worse when using the Artwork Organiser script (if set to remote location).
First extract the artwork from thumnails to put on a remote location.
Then xbmc cashes that artwork again which is located on a remote location.
So that triple?

[Jezz_X]

I know cashing speeds things up locally. However xbmc also supports placing the thumbnails folder on a remote place using the substitute function in AS.xml

So doesn't this defy the point using the cashing to speed up things?
First you cash a file because it's on a remote location and then you use supstitue to place it back at a remote location. That's twice the storage usage for no speed gain.

It even gets worse when using the Artwork Organiser script (if set to remote location).
First extract the artwork from thumnails to put on a remote location.
Then xbmc cashes that artwork again which is located on a remote location.
So that triple?

The Path substitution was just a pure luck side effect of the playlist path
substitution AS and really that should just mean 1 thumb folder for all xbmc installs and all caching to that place so you must be doing it wrong.

and "Artwork Organiser script" not really a xbmc issue really

[Martijn]

The Path substitution was just a pure luck side effect of the playlist path
substitution AS and really that should just mean 1 thumb folder for all xbmc installs and all caching to that place so you must be doing it wrong.

and "Artwork Organiser script" not really a xbmc issue really

It was just to indicate there are some drawback of the current cashing setup.

I'm sure my setup is correct
I use the centralized thumbnails for my boxes and there are no real problem with it. It is just that the cashing of fanart that is stored on remote media makes no sense if you use the substitute for thumbnails. The images are still transferred over a network so it only costs space.
Not that it's a real problem nowdays with the 3TB disks but still.

I've read that in the future it will be possible to add the textures.db (and others) to the sql servers. Is there a place where i can read how this will look? Just for my interest.

[Raytestrak]

Already asked this question in a skin thread, but maybe this is a more suitable location:

Are there folders, apart from the skin folder, that aren't cached? I'm asking because I'm using artwork organizer to split TV and Movie fanart to show random images in my home menu (Aeon Nox).

This works fine, except for the fact that when you point the multi image location to the default folder, which resides in userdata\addon_data\script.artworkorganizer, all the images get cached. When I remove the images from the folders created by artwork organizer I get NO background in my home menu. When I leave those in place and I remove my cache folders, I have no images at first, but the get rebuilt over time. Takes forever.

When I move all my artwork to the skin folder, and point the multi image location to those folders, I get all my artwork AND my cache stays empty. This is what I want, not only for diskspace, but also for the lifespan of my SSD and the fact that I never have outdated artwork. Saves me 1,2 GB's and I can safely remove 6000 files.

The skin folder gets deleted when it is updated so leaving it there isn't an option. For the time being, I've create junctions to the right folders which get recreated after a reboot or resume from sleepmode. It was either this, or make the artwork organizer store the files in the skin folder, but the skin get's updated more than I run the artwork organizer addon. Downside to this is that it's not 100% portable. Tried special://home/addon/skin.aeon.nox.svn in the guisettings.xml (special://home being the portable folder according to xbmc.log).

The real question should really be WHY are local files cached anyway? Performance wise it won't help.