XBMC "Server" - centralized XBMC management for multiple XBMC devices/platforms?

bradvido88 Wrote:For the mysql backend solution that firnsy implemented, outlined here: http://trac.xbmc.org/ticket/8169, what information is stored in the database?
I'm specifically interested in fanart/thumbnails. Are those stored in the database, or still stored locally? If locally, does this mean that each client still needs to do their own scraping in order to get the images?

Unfortunately yes, individual clients need to scrape their own thumbs. Alternatively you can scrape from a master and then sync the cached thumbs to the other boxes. A hack yes, but real solutions are being nutted out.

The proposed solution is to store the original fanart/thumb URL in the DB and where a client is missing such an image, it then has the ability to go grab it.

firnsy Wrote:The proposed solution is to store the original fanart/thumb URL in the DB and where a client is missing such an image, it then has the ability to go grab it.

Storing the URL is good enough for now. It'd be cool to see the actual images stored in the DB, but maybe down the road.

It's still the best solution i've found so far. Thanks for the hard work! I'll continue to test.

bradvido88 Wrote:Storing the URL is good enough for now. It'd be cool to see the actual images stored in the DB, but maybe down the road.

It's still the best solution i've found so far. Thanks for the hard work! I'll continue to test.

Storing the URL is only a proposed solution so far, it's not implemented yet.
Storing the images in the DB along with the URLs was also one of the options already suggested by firnsy, but the point of having a thumb cache altogether is to speed up image loading so it probably won't be the case if the cached images are stored only in a remote database, but as far as I know the topic is still an open discussion.

In theory there'd be nothing stopping you storing the thumbs on the same server as the database - the database will contain a URL to the current thumb, so that URL certainly could be on the machine the database sits on, assuming that the URL makes sense to each of the clients. All the clients see, after all, is the URL. In this sense, it's identical to that URL pointing to a thumbnail next to the media file.

I've started work on a better thumb cache - it's rudimentary at present but I'm hoping to improve it in the coming weeks.

Cheers,
Jonathan

jmarshall Wrote:In theory there'd be nothing stopping you storing the thumbs on the same server as the database - the database will contain a URL to the current thumb, so that URL certainly could be on the machine the database sits on, assuming that the URL makes sense to each of the clients. All the clients see, after all, is the URL. In this sense, it's identical to that URL pointing to a thumbnail next to the media file.

That makes a lot of sense. I like the idea of once an image is downloaded, it should be stored locally in a way that all other clients can access it. Whether it actually gets stored in the database or not is up to team-xbmc, but it makes sense to me to have all my "client" xbmc's get the images quickly from a local site, and then store them in their own cache for ever faster access when using that client.

bradvido88 Wrote:That makes a lot of sense. I like the idea of once an image is downloaded, it should be stored locally in a way that all other clients can access it. Whether it actually gets stored in the database or not is up to team-xbmc, but it makes sense to me to have all my "client" xbmc's get the images quickly from a local site, and then store them in their own cache for ever faster access when using that client.

See here for a more detailed explanation of what i mean http://forum.xbmc.org/showthread.php?p=5...post511623

I love the sound of this idea, just concerned about storing the images in the data base. Example, I have too many movies, and too many TV Shows.
It takes 2 minutes now for XBMC to load my library on my XBOX's and windows takes about 30 seconds (on an AMD Quad Core 3GigHz Processor). On Windows when I scroll through the covers it can show the first 20-30, then it shows blank icons while the rest of the thumbs are loading. If this was streamed from a database this would be significantly worse. (Due to my library size I am unable to watch movies on my XBOX due to lack of memory)

I am already going to replace my 2 XBOX's and am considering a Intel Atom and the testing I am doing now indicates it will not be much faster than my XBOX's. Whatever solution is decided I would like it to be the fastest especially with large databases.

I just wanted to state that performance needs to be considered and I am sure the developers are considering this, but I think XBMC struggles with large databases now.

The solution i proposed would still read the images from the local hard-disk cache. However, the images would also be stored in the database, so any XBMC client that does not have them cached already can download them to it's local cache.

Therefore, there would be no performance considerations for reading images as they would not be read directly from the database, except for the initial read of course

jmarshall Wrote:In theory there'd be nothing stopping you storing the thumbs on the same server as the database - the database will contain a URL to the current thumb, so that URL certainly could be on the machine the database sits on, assuming that the URL makes sense to each of the clients. All the clients see, after all, is the URL. In this sense, it's identical to that URL pointing to a thumbnail next to the media file.

This sounds like the best solution so far, rather than storing the images inside the DB it-self.
I am running the DB on my NAS at the moment so I guess if we started chucking the images inside the DB it would probably get too large for the RAM on NAS type devices ?
I we can get them just locally stored on the disk and have a 'pointer' so that clients know where to pull them from that would seem to be the best choice.

True. However, the nice thing about storing them in the database is that the process of retrieving them is OS-independent. You don't have to worry about different OS path styles and structures, or if you should use a "/" or "\" etc.

That being said, I'm sure that it won't be terribly difficult to manage the paths across different operating systems.

Both choices are good solutions in my mind.