[rbusenet]

Problem: external mysql database with externally referenced thumbnails. The data base is getting correctly updated from either device and the thumbnails are posting to the external thumbnail folder. However, the thumbnails scraped by the other device do not show up. I started with what I thought was a clean slate. Scraped tv on one and movies on the other (sequentially after the first was done). And all of the files are accessible and are on the mysql database but the thumbnails are black if they were scraped by the other device.

I have two raspberry pi's running openelec (latest version) and a mysql server setup on my FreeNAS box. I previously had my myslq server setup on my MyBook Live hard drive and everything worked like a champ. When I moved all of my movies and switched to mysql on the freeness box is when the problem started. I deleted the sources on both xbmc's as well as the texture.db on both before I switched to the new server location and new mysql / thumbnails. It's just strange that it is sort of working but only half way with the thumbnails? Any thoughts. I tried looking at the actual art locations in the msyql database and all of the thumbnails reference urls instead of the hash or file name and location on the NAS? I couldn't find any actual file thumbnail location data anywhere on the database but I also don't know where to look either? I'm fairly certain my advanced.xml is working because it was working with the MyBook live (all I did was switch up the locations). I will say that the MyBook Live was NFS and my FreeNAS is running CIFS?

Thanks for any help! I really don't want to try starting from a clean OS wipe / SD card wipe if I don't have to. I'm leaning that that wouldn't fix it anyway.

[Milhouse]

Are you sharing the Thumbnails folder? That's usually a bad idea unless you're space limited which is not usually the case on R-Pi clients. Just don't share your thumbnails, unless you also find a safe way to also share Textures13.db (and it sounds like you haven't).

[rbusenet]

Well the idea that I had working was the idea that the two could independently update an external thumbnails folder. Which worked out for me because every so often the rasp pis could crap out the sd card and it didn't matter because the library and thumbs were on the NAS. I didn't come up with the idea all on my own. It was in the old wiki that way. However (with no change in version) they added that with 12.3 you don't have to do anything now they just magically sync themselves. Well not too sure how that works beings to my knowledge nothing has really changed and the libararys never just magically synced until I updated my advanced settings and used mysql? Thoughts?

[Milhouse]

There's two parts to the Thumbnails cache (or texture cache, which may be what the Wiki is referring to) - the folder of thumbnails themselves, and the Textures13.db that XBMC uses to access the Thumbnails folder.

Both of these normally reside locally on each client. However, you're now sharing the folder of Thumbnails but not sharing the Textures13.db, so each client thinks it has access to only a subset of the images present in the shared Thumbnails folder and has no knowledge of all the other images added by every other client. That's why path substitution of thumbnails with the aim of sharing images between clients is generally a bad idea doomed to fail as you can't simply share the folder of images without also considering what you're going to do with the Textures13.db, which is a SQLite database which isn't designed to be updated by multiple clients so sharing this file is strongly advised against.

I'd say path substitution for thumbnails is only worth doing if you've got absolutely no other option, which boils down to an AppleTV with zippo storage and you need to relocate the Thumbnails folder to network storage due to lack of space. Such a scenario will work fine, just as long as you don't then share the network located Thumbnails folder with another client, as that won't work so well (as you're now discovering). The contents of the Thumbnails folder should generally be considered unique to each client - you can relocate it to the network with path substitution, just don't then share it.

My advice: Forget sharing the thumbnails, it's not worth the aggravation.

PS. Raspberry Pi corruption of the SD card is fixed with firmware made available since November. Any recent R-Pi XBMC distribution should be using the fixed firmware.

[rbusenet]

Awesome reply! That clears things up quite a bit. I guess my question now is: What is the process to get multiple xbmc's to sync up thumbnails or texture13.db's. The wiki makes it seem like it does it automatically. Does it do it on boot, on media update, or something else. I leave my xbmc's on permanently so update on boot would most certainly never sync my thumbs. What other steps do you have to do to tell each xbmc to sync with others? Simply use an external mysql database via advanced settings.xml?

Thanks again!

[Milhouse]

I guess my question now is: What is the process to get multiple xbmc's to sync up thumbnails or texture13.db's. The wiki makes it seem like it does it automatically. Does it do it on boot, on media update, or something else. I leave my xbmc's on permanently so update on boot would most certainly never sync my thumbs. What other steps do you have to do to tell each xbmc to sync with others? Simply use an external mysql database via advanced settings.xml?

Thanks again!

When sharing meta data (MySQL), you have two options when populating the texture cache on non-scraper clients (I make this distinction as the "scraper" client will already have a fully up-to-date cache):

1) As you browse the library on the non-scraper client, XBMC will automatically update the texture cache as you try to display an image that isn't already in the cache. Once an image is in the cache, it will be displayed quickly, but the initial process of retrieving, converting and caching each image can be quite slow and doesn't result in a great user experience as you have unpredictable delays whenever new artwork has to be cached.

2) Or there's the script in my sig, which is designed to pre-load the cache on a client with all new artwork, ensuring an optimal user experience when browsing the GUI. Just run it against your non-scraper clients after you have scraped new media. It also includes other options that allow you to automate media scraping and cache updating, if you're handy with scripts that is.

[rbusenet]

Awesome. That looks promising. How does the non-scraper (client) know what the other XBMC ip address is? Do they self announce? How does the server know it is the server and the client know it is the client? Or does it not get the cache from the master xbmc (i.e. internet for initial caching)?

With this method, once you have everything scraped and synced. Can the non-scraping xbmc update the library if a new movie posts/announces for example?

[Milhouse]

How does the non-scraper (client) know what the other XBMC ip address is? Do they self announce? How does the server know it is the server and the client know it is the client? Or does it not get the cache from the master xbmc (i.e. internet for initial caching)?

The clients (scraper, non-scraper) are independent of each other. The know nothing about each other and don't communicate with each other (UPnP excepted), and retrieve all their meta data via the MySQL database.

The non-scraper clients will cache their artwork from the same locations the scraper client originally used - if this is from the internet then when pre-loading the cache on a non-scraper client XBMC will download the artwork from the internet (again). Rinse and repeat for all of your (non-scraper) clients.

A risk with internet hosted artwork is that by the time you come to view an uncached item (poster, fanart) on a non-scraper client it's quite possible the artwork is no longer available to be cached (site offline, artwork physically deleted or renamed).

Pre-loading the cache on all your clients as soon as you scrape a new movie mitigates this problem to a very large extent, although using only local artwork is the best option when sharing meta-data between multiple clients.

With this method, once you have everything scraped and synced. Can the non-scraping xbmc update the library if a new movie posts/announces for example?

You can, as long as each client has a sources.xml file, but remember that only the client that performs the scrape will have a fully up to date texture cache - all the other clients will not have the new artwork present in their texture cache until it's either viewed or pre-loaded.

[rbusenet]

Perfectly clear now thanks!