Kodi Community Forum

I currently have both a living room and bedroom Kodi using a shared MySQL database. I'd like to share the thumbnail directory from the main PC (living room) with the 2nd PC (bedroom). I have added the path substition in the advancedsettings.xml. When loading Kodi on the bedroom PC the video library is shared but none of the images like posters and backgrounds show for the videos. I have looked through forums for help but so far have been unsuccessful in resolving the problem.

I have verified that Kodi is able to access the shared folder for thumbnails.
Kodi log indicates that it is reading advancedsettings.xml at start.
If I manage a video and choose a poster/background the jpgs are stored in the normal special://masterprofile/thumbnails/ folder.

Kodi acts as if a substitution was never defined.

Here is the advancedsettings.xml:
<advancedsettings>
<pathsubstitution>
<substitute>
<from>special://masterprofile/thumbnails/</from>
<to>smb://htpc/users/media/appdata/Roaming/Kodi/userdata/Thumbnails/</to>
</substitute>
</pathsubstitution>
<loglevel>0</loglevel>
<guires>1080</guires>
<videolibrary>
<dateadded>0</dateadded>
</videolibrary>
<videodatabase>
<type>mysql</type>
<host>192.168.1.100</host>
<port>3306</port>
<user>xbmc</user>
<pass>********</pass>
<name>kodivideos</name>
</videodatabase>
<musicdatabase>
<type>mysql</type>
<host>192.168.1.100</host>
<port>3306</port>
<user>xbmc</user>
<pass>********</pass>
<name>kodimusic</name>
</musicdatabase>
</advancedsettings>

Any suggestions on getting this to work?

I also had this problem, but a new copy of my advabcedsettings.xml did the job (maybe avtypo, dunno).

Path substitution is not designed for thumbnail sharing and will result in exactly the kind of problem you describe.

Path substitution of thumbnails will only work reliably for one thumbnail folder with one client (one-to-one).

Sharing one thumbnail folder between multiple clients (one-to-many) is *not* supported or recommended, and simply does not work.

Since when isnt it recommend? I remember frodo dropped support? But then gotham wiki was updated to include shared thumbs... Now no share again?

Thumbnail sharing has never been recommended as far as I can recall - the caching mechanism simply isn't designed to support sharing without experiencing the problems described in this thread. And if you go the whole hog and attempt to share the Textures13.db as well, then you'd be risking database corruption too. It is possible that thumbnail sharing may appear to be working, but the likelihood is that you're slowly corrupting your shared cache with each client repeatedly overwriting the cache entries already created by other clients, potentially with lower quality image settings etc.

Path substitution of the thumbnail folder is intended (and recommended) for single clients that don't have sufficient local storage, allowing such clients to relocate their (and only their) thumbnail folder somewhere else, eg. to a network location.

Path substitution is not, and never has been, a mechanism to allow multiple clients to *share* a single thumbnail folder (if this has ever been recommended in the past, it was in error).

If there is a current section of the Wiki that suggests thumbnail *sharing* is technically feasible via Path Substitution then please provide a link so that it can be removed, as it's total BS. It doesn't work, can't work, will never work.

http://kodi.wiki/view/Path_substitution

It is not about sharing (also not forbidden), but i read it somewhere here inside the forum and it works fine on my 4 devices.
No problems, but if you already wrote: without guarantee and of your own risk.

(2015-01-21, 22:35)Starscream Wrote: [ -> ](also not forbidden)

Not forbidden, but should be.

(2015-01-21, 22:35)Starscream Wrote: [ -> ]and it works fine on my 4 devices.

Unfortunately, that's just an illusion, as your 4 devices are overwriting each other in your shared Thumbnails folder.

For example, Client #1 looks in it's Textures13.db, doesn't find a row for a cached image so proceeds to create a new cached image in the shared Thumbnails folder, overwriting whatever is already there. Clients #2, #3 and #4 will do the same, until they all have a row in their local Textures13.db.

This situation isn't so bad when all 4 devices are using the *exact* same image resolution properties, however if the final device to create the cached image (Client #4 in this example) has low quality image settings (eg. a Pi), then clients #1, #2 and #3 will now show the same low quality cached artwork next time they display the image, when previously they may have shown much higher quality artwork. Consider this "cache contamination" rather than outright corruption.

Further problems arise when cached artwork is removed from the shared Thumbnails folder but rows still exist in the Textures13.db of one or more clients - these clients then fail to display the missing artwork ever again, as they think it should be in the cache but then fail to find it in the Thumbnails folder - they won't recreate the cached item when this happens. So you're screwed, like the OP, whose local Textures13.db is most likely out of sync with the actual contents of the shared Thumbnails folder.

You may think you are benefiting from having a prepopulated cache by "sharing" a Thumbnails folder - add a new client and hey presto, it's Thumbnails are already present, nothing to cache. Except they're not already there (as there is nothing in Textures13.db), so the new client still has to go through the process of caching everything it displays, overwriting any cached artwork that may already be in the cache from your other clients. You could copy over the Textures13.db from one of your other clients which would bring the new client up to speed, but who does?

Sure, you save on storage space with a shared Thumbnails folder, but at the risk of contamination/corruption of the cache. Since the shared Thumbnails are likely to be on a network drive, is it really worth it - the extra hassle, the extra risk of contamination/corruption? Just use individual shared Thumbnail folders, one per client - as it was intended to work when using Path Substitution - if you *really* need to relocate the Thumbnails for a local storage deprived client. Otherwise stick with local Thumbnail folders, as they work best (most reliable, best performance).

And sharing the Textures13.db is an absolute no-go, so that's not really a solution.

I understand the problem and will substitute to 4 different folders now (never knew what this local DBs good for).

But 2 remarks here:
- plz edit the wiki
- why are there further local databases if you switch to MySQL?

I guess it is about technical reasons (history?), but sounds strange to me.
Could be a good task for 15.0!

(2015-01-21, 23:46)Starscream Wrote: [ -> ]- plz edit the wiki

Yes, I think it's about time.

(2015-01-21, 23:46)Starscream Wrote: [ -> ]- why are there further local databases if you switch to MySQL?

I guess it is about technical reasons (history?), but sounds strange to me.

My guess because there's never been any reason to switch the Textures13.db to MySQL - the entire caching solution is simply not designed to be shared, and there is little benefit to be gained from doing so.

One of the primary goals of the Texture Cache is to improve performance, by ensuring all the required artwork is available locally and not on the network (or worse, the internet), and stored in the most optimal format for the client device that is going to be displaying the artwork (this may mean using lower resolution, changing format from progressive jpg etc.).

Moving the cached artwork back on to the network goes against the fundamental goal of performance, and since every client device could also have different image resolution requirements it makes even less sense to try and maintain a shared cache when every client has different caching requirements.

There is really no need for anyone to configure a "shared" Thumbnail cache - there is no benefit, only added complexity and problems, so I don't see the implementation of Textures13.db changing any time soon.

Wiki updated.

My network is realy fast as my NAS is.
So i never had trouble with all the files, but took advantage of the consistecy data (never had trouble).
I realy hate redundance of data, but as i wrote before: all fine with further substitutions.

Maybe one time the team will decide to create a shared DB fot thumbnails.
No high priority ofc, but a nice idea.

But there are more important features to implement i guess

Thanks a lot for your explaining.

I've been running shared thumbnail folder for years, no issues. It wasn't till I needed the translated path in my xbmc plugin that I noticed the "limitations" of using it. I dont see why it can't be supported by Kodi.

Hi All, I've previously used pathsubstitution for sharing thumbnails as I had a couple of ATV2. These have now gone and I would like to remove the string from my advancedsettings.xml. As the current thumbnails are located on an SMB share is there something I should do before removing the string to relocate the thumbnails?. I use MYSQL. Thanks

No, just remove the path substitution entry from advancedsettings.xml, and delete the Thumbnails folders from your SMB share.

(2015-04-09, 23:26)Milhouse Wrote: [ -> ]No, just remove the path substitution entry from advancedsettings.xml, and delete the Thumbnails folders from your SMB share.

Thanks, just done, at the moment no art appears does it just take a while for the thumbnails to be reloaded?