+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Feature Suggestions (/forumdisplay.php?fid=9)
+--- Thread: XBMC "Server" - centralized XBMC management for multiple XBMC devices/platforms? (/showthread.php?tid=37315)
Potential as a commercial solution for hotels, hospitals, airplanes, and... - Gamester17 - 2008-09-20 22:30
Rand Al Thor Wrote:Correct, but in my head I imagine an XBMC solution like that could have the potential of being made popular as a commercial solution for hotels, hospitals, airplanes, and other internal on-demand TV services, and for those type of solutions they would only need instances of XBMC in which the gets userdata gets restored from the master after use, after a reboot if you may.Gamester17 Wrote:userdata would synchronize out from the master to the slaves in realtime or update when they boot if they been turned off.Only issue I could see with that is that watched/unwatched wouldn't get updated if you watched a movie on one of the slaves, correct?
- wells - 2008-09-20 23:03
Gamester17 Wrote:I imagine an XBMC solution like that could have the potential of being made popular as a commercial solution for hotels, hospitals, airplanes, and other internal on-demand TV services
For this a 'Kiosk' Mode would most definitely need to be established as discussed in other threads, correct?
- Rand Al Thor - 2008-09-21 17:22
Gamester17 Wrote:Correct, but in my head I imagine an XBMC solution like that could have the potential of being made popular as a commercial solution for hotels, hospitals, airplanes, and other internal on-demand TV services, and for those type of solutions they would only need instances of XBMC in which the gets userdata gets restored from the master after use, after a reboot if you may.
While I definitely agree with you that this would be the perfect solution for instaces such as Hotel implementation as you mentioned previously where keeping track of watched/unwatched would not make any sense, I would still like to see a way of keeping multiple databases up to date on a smaller scale. For example I will end up having 3-5 instances running in my house with about 3 unique user accounts. It would be nice to centralize and be able to keep at least a small number of xbmc devices synced.
One other thing I wanted to mention on this topic. Keeping the databases centralized is pretty much a given but we should give some thought to guisettings.xml. It should either be left on the individual instance or have some way of making a separate guisettings.xml for each xbmc device NOT just for each user. Some people might have a 1080p monitor in the living room and 4x3 standard def tv in the bedroom. You would definitely want different resolution, skin, etc. Just some thoughts I had been mulling around. Cheers.
2 computers 1 library - psike - 2008-09-21 18:18
I'm using XBMC on 2 PC's. My computer is the host for all the movies and the other one use a SMB share.
Is it possible for the other PC to use the same library from my computer, instead of creating another one?
- cellopoly - 2008-09-21 19:06
I have the same type of setup and I use the XBMC Media Companion to create nfos for all my videos. Then just have XBMC library auto update on load.
- psike - 2008-09-21 19:14
That exactly how i used it until now, but now there is a new scrapper that get info in my language so I prefer use it over XBMC Media Companion.
So I need another idea to work around it.
- t029248 - 2008-09-21 19:17
I'm using also multiple XBMC instances and it would be great if i could put the library on a shared network location.
- shl-pl - 2008-09-22 00:23
I'm not sure what will happen if you fire 2 instances of XBMC and each one will try to lock any of the library files at the same time. But you can edit userdata\profiles.xml and change the location of <directory/>, ie.:
<directory>E:\Whatever you want</directory>
This would make XMBC to save \Database, \Playlist, \Thumbnails and \Visualisations folders at the given location. You can put there advancedsettings.xml, favourites.xml and sources.xml files as well.
- althekiller - 2008-09-22 00:42
Problem with the current way things are handled in instances like; start XBMC0, start XBMC1, update XBMC0, XBMC1 won't see updates cause it doesn't know anything. Problems become increasingly problematic with stuff like watched. There would have to be a centeral server that handles the transactions and pushes and pulls as necessary. There is another thread about this, search "OFDB".
EDIT: "ODBC" not "OFDB"
"Miniconf" from the Moblin.org project? - Gamester17 - 2008-10-15 14:08
If XBMC already had ODBC support then perhaps "Miniconf" could be implemented as a base to manage the other requirements?
http://moblin.org/projects/miniconf
Quote:Miniconf a lightweight version of a gconf style key management system which trims out all features that are unnecessary for the mobile environment. Mobile platforms tend to be decentralized multi-user system with users logging in one at a time. Global administration is usually fixed by the OEM with administrative control of the user environment shifted to the user him/herself.PS! Checkout this other related but still off-topic feature suggestion => http://forum.xbmc.org/showthread.php?tid=24415
Miniconf operates from the perspective that each user's environment is unique and separate. It satisfies the following basic requirements:
1) Settings Key/Value pairs: An application running on the system should be able to create an unlimited number of settings keys which support all the basic types that DBUS supports: integer, unsigned integer, string, boolean, double, and arrays of the preceding.
2) Notifications on change: Keys should support registering callbacks which send notifications on changes to the key, reads, writes, or deletes.
3) Readable Database: All the keys, their owners, actions, and permissions should be stored in a database for retrieval on boot or applications settings manager restart. The database will reside in the user's home directory.
4) Key Ownership: The application which creates a key should be recorded as the owner of the key (by recording its binary path) and should be able to set notify, read, write, and delete its keys at will.
5) Key Permissions: An owner application should be able to establish permissions on whether other applications can register for change notify, read, write, or delete a key.
6) Control Keys: An owner can designate a key as controlled, which disables writes/deletes for apps other than the owner. When a caller changes the key, the owner is notified with the requested change, and decides whether to allow the change by either returning fail (which sends a fail to the caller), or by returning pass (resulting in the change and notifications for reg'd apps).
The first three requirements are also satisfied by gconf, but with gconf the database is stored centrally in /usr/share and is mirrored to every user's home directory. For our purposes we will maintain a single database in the user's home directory, one that is visible only to that user. The last three requirements are additions to gconf functionality that improve security and expand the functionality of key/value pairs.