[nickr]

I am fairly new to XBMC but I am loving it. I am a long time mythtv user, and I still use that for recording. But I much prefer XBMC's interface and the metadata scraping support.

I want to have a system with my media on a server and a number of xbmc clients around the house, all having access to the server.

It seems that each client has its own database, which seems a little crazy for my situation. I see little point in downloading movie/tv show metadata for each client.

I have searched here a little and can only find some fairly old threads about this. Knowing that development goes pretty fast and a thread from 2007 may be completely out of date, I was just wanting a pointer to how other people handle this.

I guess one way to handle it would be to use one client as the "master" and do all scraping there. And then somehow export that data to all the other clients.

Or has someone developed a way to make use of just one central database for number of clients?

[Hitcher]

I just use MIP so all the data is stored with my videos/music and each machine reads from there.

[dalvis]

I too would like to see some kind of central management of XBMC, this would be especially useful with the Live version.

Perhaps a more elegant solution would be instead of mounting the userdata, use the existing built in web server to share the configs and thumbnails. Since the idea is a master/slave relationship, the slaves don't need to change the master config, they just need a copy of it. I think that keeping the local cache of configs and thumbnails is a good idea, especially if the master goes down for any reason.

This way, the slaves can send a request out to sync with the master, possibly by specifying an address or some kind of auto-detect method. This would keep slave configuration a simple as possible. Of course for the paranoid, this might lead to wanting a username and password for the config sections of the web server, which would require a little more config at the slave. Or, it could even be moved to a real web server and updated manually.
As for the the thumbnails, probably should have it poll the master when it looks for a thumbnail for the first time, that way if it has been updated, it can get that. Otherwise it can get it through the normal channels is uses now.

Of course the database is the tricky part, as stated the SQLlite won't work in a shared environment. Perhaps a hybrid of what has been proposed would work. Store the master data in a MySQL database and then have the clients replicate that to the local SQLlite database. Of course that may end up being more trouble than it is worth in trying to sync the DB, especially if multiple versions of XBMC are in the network.

I think getting a shared master config, at least the sources.xml, would be pretty easy, especially if using the web server. Providing a master repository for the thumbnails would probably also be fairly easy too. It would probably work as a variation on the existing scrapers, except it would be for the config and cache data. Even if the database has to manually updated or copied, having the first two would speed up the other operations because it would not have to resize all the thumbnails again.

Just my 2 cents.

[nickr]

The ideal in many ways would be one machine with all the config on it using a proper RDBMS. The sqlite docos say

Situations Where Another RDBMS May Work Better

*

Client/Server Applications

If you have many client programs accessing a common database over a network, you should consider using a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

A good rule of thumb is that you should avoid using SQLite in situations where the same database will be accessed simultaneously from many computers over a network filesystem.

So you'd need to use something else like MySQL, which in turn would require a major internal change to XBMC. You'd also want to have alternatives - SQlite for those who want a simple one machine setup, and a RDBMS option for those who want a house full of the things. I doubt the devs want to go there.

For one thing the "ease of use" would diminish. As a long time user and supporter of MythTV, which uses MySQL in the backend, one of the biggest stumbling blocks for a beginner is setting up the MySQL access for frontends. If you get it right first time its easy, but muck something up and you're in for a hard time. Also MythTV pretty well runs only on one OS (yes there is also OSX ports and windows frontends but they are very much minority situations). On XBMC you have to cater for Windows, OSX, Linux, xBox and the livecd. I have never set up MySQL on windows, I know it is possible but windows users do not generally want to be mucking about with text config files and console apps.

The solution between ease of use and some sort of centralisation? I dunno. However I suspect duplication of the SQlite database files by copying them from a master store might be the way to go, unless someone is willing to try and code a MySQL backend data store, and a whole new database layer in XBMC.

[bidossessi]

So you'd need to use something else like MySQL, which in turn would require a major internal change to XBMC. You'd also want to have alternatives - SQlite for those who want a simple one machine setup, and a RDBMS option for those who want a house full of the things. I doubt the devs want to go there.

Hi this is my first post, but i'm an avid follower of xmbc especially as a whole-house media management solution (PVR and all).

I should think that people who want a whole house setup are ready to go the extra mile required (such as setting up an 'X'SQL server). most of the people who follow xbmc-pvr branch already have one setup (mythtv-backend). i believe an extra option or two could be added to the SETTINGS section offering to choose between local and remote DB, with potentially running a creation script for the different databases required as long as the user specifies which type of DB he's using (MYSQL, PGSQL, etc... in a dropdown menu), and, if applicable, give a UID to the XBMC instance being setup to allow multiple instance keep integrity while still using the same remote backend.
This way, other projects like "follow-me" could get a strong push.
The issue where backend could be offline is the same for either XBMC or Myth, but that hasn't stopped Myth users. xbmc has the possibility of falling back to it's local SQLite DB if need be. Redundancy might even be a good idea:
Assuming each instance of XBMC has both local and remote sources, if backend is online, each instance has access to both local and remote media on the backend. Instance-to-instance sharing is already available through the included uPnp server so that's not much of an issue.

I really believe this ODBC step is the next crucial step.

Whether the devs intended it or not, XBMC has become a reference in temrs of Media Center, and a lot of people are building whole-house systems with a backend/storage center and multiple XBMC instances.
It seems only natural to follow that trend, without loosing what already exists.

I see XBMC becoming the best LinuxMCE frontend available, since it can use what is already being done in other OSS projects. All that needs to be done is keep a door open.

[nickr]

most of the people who follow xbmc-pvr branch already have one setup (mythtv-backend).

How do I do that? ie follow the xbmc-pvr branch?

[jmarshall]

Sqlite is already abstracted from the main database layer. You'd "just" need to add the other underlying layer for whatever other database you want to use.

A patch would, ofcourse, be most welcome. It's not something the main dev crew are likely to work on at this point - not enough of us use it in a multiple room scenario to warrant the effort. We will, however, offer assistance to anyone wanting to take a crack at this.

Once that's done, there'd have to be some changes (multiple user watched counts for instance) to the library layout most probably.

Cheers,
Jonathan

[RockDawg]

It's a shame that this can't even be put on some future to do list. Especially when there is already going to be some reworking of the video db to come.

[jmarshall]

No point putting on some future to do list that never gets done - the only thing that accomplishes is to give false hope

In the meantime we wait until someone with the time and motivation works on it.

Cheers
Jonathan

[RockDawg]

No point putting on some future to do list that never gets done - the only thing that accomplishes is to give false hope

Cheers
Jonathan

I know, and that's exactly what I meant. It's a shame that any hope for implementation would be false hope at this time, and that this feature is not thought important enough to be considered forthcoming at some point. This isn't some fringe, little-to-be-used feature request. In my years on XBMC related forums, I have seen this requested over and over again. It's usefulness is obvious and it would benefit many (even if not many of the devs).

I realize, and am appreciative, that devs do this free of charge and in their own spare time. Thanks for XBMC regardless!

[nickr]

Just thinking ahead to a central SQL server for the database, would we want some sort of priority for users to make changes.

ie I don't want the kids mucking up my nicely set up metadata by deciding they prefer the descriptions from imdb when i like the ones form themoviedb.org, etc.

[bidossessi]

there is a post about a Unified media manager that would take care of central db management (scraping, sorting, etc)...
This application should be located on/interfacing with the db server, if I understood the intention correctly, thus restricting access somewhat. I believe what it is supposed to do is take over all scraping and sorting work (abstracting it somewhat).

[feerlessleadr]

there is a post about a Unified media manager that would take care of central db management (scraping, sorting, etc)...
This application should be located on/interfacing with the db server, if I understood the intention correctly, thus restricting access somewhat. I believe what it is supposed to do is take over all scraping and sorting work (abstracting it somewhat).

just fixed the link for you

[rossgemuend]

Would the centralized DB allow for one to start watching something on one XBMC instance, and then transfer it to another XBMC instance? I would love to see this ability or maybe even being able to stream the same movie to multiple XBMC instances simultaneously.

[nickr]

Would the centralized DB allow for one to start watching something on one XBMC instance, and then transfer it to another XBMC instance? I would love to see this ability or maybe even being able to stream the same movie to multiple XBMC instances simultaneously.

It would probably allow a bookmark to be transferred from one instance to another, so you could go to the other room and start from where you left off.

Precise synchromisation between instances, so two screens are exactly matched in time is not something that a simple fix to the database backend could do. It requires changes in the player. It is not a trivial exercise. It is off topic in this thread. There are plenty of other threads about synchronisation.