[jmarshall]

Yes.

[bradvido88]

I still used shared thumbs with frodo. I did have to reset my textures.db (rename to textures.old.db) when i moved from eden to frodo though.

[supahfly]

What do u mean with restting textures.db?
I also upgraded to frodo yesterday; with the mysal database on the NAS
A new DB was created; no issue there; but the path substitution seemed to fail since all of my art work was not there, neither were my thumbs
I was also very happy with the way things worked in Eden.
How do you recommend people with thumbnails on a NAS server, and a shared mysql database on that same NAS to configure their Frodo boxes?

[jmarshall]

1. Update a client. You'll be prompted to rescan video art when you go into videos.
2a. Optionally, copy userdata/thumbnails (you can drop the video and music subdirs) from the server to all clients.
2b. Or remove textures.db on that client.
3. Once done, remove path substitution.
4. Update all other clients.

If you really want to keep art on the NAS (not recommended) then just do what you've always done. Note that all clients will "recache" textures while they update their textures.db, so you could potentially end up with corrupt art files, though this is relatively unlikely.

Cheers,
Jonathan

[moontan77]

1. Update a client. You'll be prompted to rescan video art when you go into videos.

I'm not sure what you mean by update a client? Update to Frodo?

I know its not supported! but i have installed a frodo version of openelec on my client and removed the thumbnail path substitution from the advancedsettings and thumbnails are very slow to load and do not appear instantly if you go in and out of movies etc.

I dont get any prompt about rescanning video art.

[xexe]

The new art caching scheme is very clever however I see no means of avoiding its inherent upstream art supplier inefficiency.

i.e. In Frodo I see no way to not download every image multiple times (for me 5 times).

How can I avoid this?

[Ned Scott]

That's actually far more efficient than what we did with pathsubs, where the same data would be transferred every time you loaded movies or tv shows. There's really not a lot of difference between re-downloading it from the internet 5 times to each client than if you had copied it to each client from within the network. Image data isn't very significant. If it's a big enough issue for the initial library scan/setup/whatever, then copy the textures DB and thumbnails folder between clients.

[xexe]

Ned Scott thanks for the reply.

That's actually far more efficient than what we did with pathsubs, where the same data would be transferred every time you loaded movies or tv shows. There's really not a lot of difference between re-downloading it from the internet 5 times to each client than if you had copied it to each client from within the network. Image data isn't very significant.

In my case transfer speed from my central storage is over 1000 times faster than my internet connection. For me I estimate system wide in Frodo there will be 1,600,000 art images (320,000 duplicated 5 times) so obviosuly I have to carefully plan this.

If it's a big enough issue for the initial library scan/setup/whatever, then copy the textures DB and thumbnails folder between clients.

That makes sense.

For clarity though after this initial sync (so during day to day usage), from earlier comments in this thread it was suggested that if the art exists locally before textures.db is updated from mysql will XBMC use this art or re-download it?

[jmarshall]

Textures.db is local to each client, just like the art is local to each client. The only thing stored in mysql is the URLs from which to find the art.

[bradvido88]

I share my textures.db between all my XBMC's and it works great for me on Frodo. Basically works the same as eden if you are using centralized thumbnails.
Note this is not recommended because sharing sqlite .db files is usually asking for trouble and not a good practice... but what can I say. Works for me and always has with XBMC.

[xexe]

Textures.db is local to each client, just like the art is local to each client. The only thing stored in mysql is the URLs from which to find the art.

yup understood. I am just trying to understand the implications IF a user upgrades a multi XBMC system home that uses shared art path sub.

In this scenario frodo art (i.e. using the new frodo hash type) could exist on a system before textures.db actually needs it. So the quesiton is if an image exists BEFORE textures.db needs it will Frodo use the existing image or ignore it an grab it again

I share my textures.db between all my XBMC's and it works great for me on Frodo. Basically works the same as eden if you are using centralized thumbnails.
Note this is not recommended because sharing sqlite .db files is usually asking for trouble and not a good practice... but what can I say. Works for me and always has with XBMC.

Appreciated but I am evaulating the implications of Frodo upgrades for OpenELEC users. We cant recommend something that risky as the userbase is to big.

[jmarshall]

It'll ignore it and grab it again. The textures database is king. If it isn't in there, then it's ignored (this is for a good reason - it could otherwise be that we're replacing an old version of the image for example).

[j114]

Half of the concern over this issue can easily be remedied by changing the way you have your media setup. The Internet bandwidth consumption can very easily be overcome by storing all of your artwork with your media files in the first place. Really, this is a best practice for HTPC users anyway, as most HTPC frontends will recognize and honor this system, rather than pulling new artwork from the Internet for each client.

First, you need to catch up all of the current media that you have. Export your current library so all of the current artwork is stored alongside your media.

Download and install one of the many great tools out there for handling artwork, metadata, trailers, etc. In no particular order, a few options are:

Ember Media Manager
Media Center Master
Meta Browser

There are other options as well, but those 3 were on the tip of my tongue. All of them have strengths and weaknesses based mostly on personal preference. All of them do a really good job in their own right.

Once you pick the tool you want to use and spend some time getting to know it and configuring it to your liking, you can then re-scrape all of your current media (assuming you WANT to) to add any missing elements or update anything you don't like. After you re-import your library, you will have all the same artwork, metadata, trailers, etc. on each client without hitting the Internet once.

Going forward, have any new media that is added to your system scraped by one of the above tools before adding it to XBMC. Then XBMC will never hit the Internet for anything relating to the new media. Now you are scraping one time and it is all stored with the media so XBMC doesn't need to use any bandwidth regardless of how many clients need artwork. Now your Internet bandwidth consumption is as slim as possible, regardless of number of clients and number of textures db's. Best of all, it can all be fully automated if you set everything up right.

As far as central storage, I will also agree that XBMC can be a serious disk hog when it comes to artwork. I have had clients with thumbnail caches in excess of 10 gb's on more than one occasion. For that reason, I eventually migrated to a shared thumbnails cache utilizing symlinks to avoid any disk space concerns on my limited capacity clients. With Frodo, as discussed, this becomes more challenging.

I've been on the nightly builds for all of my clients for a few months now, so I have had time to experiment and figure out what method will work best for me, long term. At first, I said to hell with "recommended". It's not "recommended" to have unprotected sex, but everyone knows it's better. I just left my original symlinks in place for my thumbnails cache and set up a shared textures.db. I backup all of my XBMC shared stuff on a nightly basis and store backups for 2 weeks. I figured if either the db or the cache itself became corrupted, I should notice pretty quickly and could just pull the most recent non-corrupted backup out and be back up and running in 5 minutes. Easy enough. Then I started thinking about the efficiency of that and didn't really like it as a long term solution. Corruption is almost certainly inevitable, and while relatively easy to overcome in my situation, I still prefer doing as little as possible (read virtually nothing).

So I started flirting with just using a local textures.db on each client with a single shared cache. Same concerns, and took me all of 3 days to have to whip out a backup of my cache directory. Screw that, next please.

So while considering how else I could make this work to my liking, it occurred to me how incredibly stupid I was being about the whole thing. The problem is simple, and I was trying to come up with a complex solution. Some of my clients have limited disk space, and I simply will not consider keeping a local cache on those drives because I absolutely will have issues with disk space. XBMC is just not ready for limited capacity and large ever-evolving collections. However, I have been storing all of my shared stuff on my massive NAS and using symlinks to share everything. Well, I have a ton of space on that NAS, and while the thumbnail cache can get overly excessive at times, it's never going to get so large that it even puts a dent in my NAS. So, duh, why am I so concerned about all of my clients using the SAME cache via symlinks when I can let each client keep it's local textures.db and symlink to a unique cache folder on the NAS?!

So now, I have a different cache directory for each of my clients stored on my central server (thus not consuming precious disk space on limited clients) with no risk of one client corrupting the cache or database for all the other clients. Seriously, even if you have 10 clients with their own cache on your NAS (which you probably expand regularly so you can add more media anyway), how much disk space would this realistically consume in the long term as compared to the amount of space you will consume adding more media? So why does it need to be a shared cache with the new textures.db system that is going to "sync" the same artwork for each client anyway?

In conclusion, would it be nice if XBMC could do all of this for me without my having to think or use external tools? Personally, I think it would be nice if XBMC would have some nice warm waffles waiting for me in the morning, but until it does I'll continue to get out of bed 2 minutes earlier and throwing some Ego's in the toaster.

Depending on your system(s) and network configuration, YMMV. For me, this is an ideal solution for my storage concerns, and the speed is plenty fast enough that I don't spend time waiting on artwork to load. I CAN see a difference in speed, but we're talking milliseconds, not minutes-- doesn't bother me at all.

[xexe]

It'll ignore it and grab it again. The textures database is king. If it isn't in there, then it's ignored (this is for a good reason - it could otherwise be that we're replacing an old version of the image for example).

jmarshall put that way it makes ultimate sense. Am I right in saying some platforms scale down images by default e.g. RPi. The obvious implications of this is that two files from the same URL which have the same hashed filename will contain different contents.

I know we are in feature freeze so I dont make this as an actual suggestion nowbut for me at least in the future it makes sense to have a feature where XBMC (via as.xml) can be told to check and/or write to a central file share for artwork. This would be separate and in addition to the current mechanism. Put another way "if image X is from URL Y is needed check central repository Z for availably before trying to download from internet. I believe this would reduce the load on sites such as TVDB and open up the possibilty of user communitys sharing a seed of art cache to further reduce upstream load.

Half of the concern over this issue can easily be remedied by changing the way you have your media setup. The Internet bandwidth consumption can very easily be overcome by storing all of your artwork with your media files in the first place. Really, this is a best practice for HTPC users anyway, as most HTPC frontends will recognize and honor this system, rather than pulling new artwork from the Internet for each client.

First, you need to catch up all of the current media that you have. Export your current library so all of the current artwork is stored alongside your media.

Download and install one of the many great tools out there for handling artwork, metadata, trailers, etc. In no particular order, a few options are:

Ember Media Manager
Media Center Master
Meta Browser

There are other options as well, but those 3 were on the tip of my tongue. All of them have strengths and weaknesses based mostly on personal preference. All of them do a really good job in their own right.

Once you pick the tool you want to use and spend some time getting to know it and configuring it to your liking, you can then re-scrape all of your current media (assuming you WANT to) to add any missing elements or update anything you don't like. After you re-import your library, you will have all the same artwork, metadata, trailers, etc. on each client without hitting the Internet once.

Going forward, have any new media that is added to your system scraped by one of the above tools before adding it to XBMC. Then XBMC will never hit the Internet for anything relating to the new media. Now you are scraping one time and it is all stored with the media so XBMC doesn't need to use any bandwidth regardless of how many clients need artwork. Now your Internet bandwidth consumption is as slim as possible, regardless of number of clients and number of textures db's. Best of all, it can all be fully automated if you set everything up right.

As far as central storage, I will also agree that XBMC can be a serious disk hog when it comes to artwork. I have had clients with thumbnail caches in excess of 10 gb's on more than one occasion. For that reason, I eventually migrated to a shared thumbnails cache utilizing symlinks to avoid any disk space concerns on my limited capacity clients. With Frodo, as discussed, this becomes more challenging.

I've been on the nightly builds for all of my clients for a few months now, so I have had time to experiment and figure out what method will work best for me, long term. At first, I said to hell with "recommended". It's not "recommended" to have unprotected sex, but everyone knows it's better. I just left my original symlinks in place for my thumbnails cache and set up a shared textures.db. I backup all of my XBMC shared stuff on a nightly basis and store backups for 2 weeks. I figured if either the db or the cache itself became corrupted, I should notice pretty quickly and could just pull the most recent non-corrupted backup out and be back up and running in 5 minutes. Easy enough. Then I started thinking about the efficiency of that and didn't really like it as a long term solution. Corruption is almost certainly inevitable, and while relatively easy to overcome in my situation, I still prefer doing as little as possible (read virtually nothing).

So I started flirting with just using a local textures.db on each client with a single shared cache. Same concerns, and took me all of 3 days to have to whip out a backup of my cache directory. Screw that, next please.

So while considering how else I could make this work to my liking, it occurred to me how incredibly stupid I was being about the whole thing. The problem is simple, and I was trying to come up with a complex solution. Some of my clients have limited disk space, and I simply will not consider keeping a local cache on those drives because I absolutely will have issues with disk space. XBMC is just not ready for limited capacity and large ever-evolving collections. However, I have been storing all of my shared stuff on my massive NAS and using symlinks to share everything. Well, I have a ton of space on that NAS, and while the thumbnail cache can get overly excessive at times, it's never going to get so large that it even puts a dent in my NAS. So, duh, why am I so concerned about all of my clients using the SAME cache via symlinks when I can let each client keep it's local textures.db and symlink to a unique cache folder on the NAS?!

So now, I have a different cache directory for each of my clients stored on my central server (thus not consuming precious disk space on limited clients) with no risk of one client corrupting the cache or database for all the other clients. Seriously, even if you have 10 clients with their own cache on your NAS (which you probably expand regularly so you can add more media anyway), how much disk space would this realistically consume in the long term as compared to the amount of space you will consume adding more media? So why does it need to be a shared cache with the new textures.db system that is going to "sync" the same artwork for each client anyway?

In conclusion, would it be nice if XBMC could do all of this for me without my having to think or use external tools? Personally, I think it would be nice if XBMC would have some nice warm waffles waiting for me in the morning, but until it does I'll continue to get out of bed 2 minutes earlier and throwing some Ego's in the toaster.

Depending on your system(s) and network configuration, YMMV. For me, this is an ideal solution for my storage concerns, and the speed is plenty fast enough that I don't spend time waiting on artwork to load. I CAN see a difference in speed, but we're talking milliseconds, not minutes-- doesn't bother me at all.

j114 thanks for taking the time to reply. Unfortunately I cannot recommend the use of external media and nfo tools as OpenELEC is intended to be a native XBMC tool. Also this approach is definitely not best practice since it has other implications. For instance for me if I was to follow this approach instead of one cache disk spinning up it is theoretically possible that XBMC would cause the spin up of over 60 hard disks all in the name of retrieving a bunch of tiny image files. Also not all file systems are configured to save the modification time of an image which means for some to know if an image is new the image itself would need to be read (as the file name and date stamp may not have changed). I am sure this approach works for many people but its not for us. ta

[Ned Scott]

j114 thanks for taking the time to reply. Unfortunately I cannot recommend the use of external media and nfo tools as OpenELEC is intended to be a native XBMC tool. Also this approach is definitely not best practice since it has other implications. For instance for me if I was to follow this approach instead of one cache disk spinning up it is theoretically possible that XBMC would cause the spin up of over 60 hard disks all in the name of retrieving a bunch of tiny image files. Also not all file systems are configured to save the modification time of an image which means for some to know if an image is new the image itself would need to be read (as the file name and date stamp may not have changed). I am sure this approach works for many people but its not for us. ta

It doesn't work like that.

Media manger downloads all images once and places them along side your media.

Each XBMC scans media only once and makes a local cached copy of the images it found with the media.

Now each XBMC instance has it's own specific cached copy of the image, and it won't access the image-with-the-media again, which is the same behavior as if it had downloaded the image.