Syncing multiple clients without SQL ?
#1
Hi,

I have a bunch of XBMC clients. They're often different versions, so I can't use SQL to synchronize.

Each client has a profile defined for it.

I manage all changes to profiles only on one 'master' machine.

That master has R/W access to all media which is on an NFS store. Each client has R/O access to the media.

To get everything sync'd, after I make changes on the master to any of the client profiles, I rsync the entire "/home/user/.xbmc" from the master to each client.

This procedure seems to be working OK mostly.

I have two questions about how things do/should work:

(1) I'd like the 'watched state' history for each client to remain unique to the client. The way I'm doing things now, the master->client rsync overwrites that state history.

What's a better way to manage the state AND still rsync changes from the master?

(2) I've set up LiveTV/PVR. Each client should have the ability to view/record/schedule LiveTV & PVR tasks, but they should be aware of one another. For example, I want to make sure that if ClientA has already scheduled both TV input channels for a task at a particular time, that ClientB can (a) see those tasks, and (b) not clobber them.

I'm not clear how that data is managed, and what media-store &/or /home/user/.xbmc permissions each client needs in order to get this right.

Any hints on how to do this right? I'm wondering if advancedsettings.xml needs to play a part in "all this"?
Reply
#2
so you're sharing the sqlite db ?
it's really not recommended by the team.

why your clients aren't the same version?

if you update only on stable, not much work, db version doesn't bump each version.
Reply
#3
(2013-07-30, 21:25)ppic Wrote: so you're sharing the sqlite db ?

Well, depends on how you define 'sharing'. I'm offling rsync'ing the sqlite DBs. Each client ends up with its own instance. There's never concurrent usage of a single DB instance.

Quote:why your clients aren't the same version?

One's on pivos, one's raspberry pi, one's Frodo built from packages on an Atom/Ion box, two are Gotham builds on big linux/64 boxes.

Quote:if you update only on stable, not much work, db version doesn't bump each version.

Sure. But I'm trying to learn how to sync my current heterogeneous environment.
Reply
#4
You could sync everything but the video database, that way you'd get to keep the watched state separated on all your boxes. You'd have to update your library individually on all machines though (which can be automated).
Reply
#5
(2) is not really a possibility since there is no way for PVR to be aware of what your other boxes are doing.

(1) this can only be achieved if each box has its own DB (not synced) meaning when you add a new media file each XBMC must update on there own.

There are only 2 official ways of sharing, MySQL and UPNP and since UPNP doesnt support watched flag yet(in Frodo) that wont work for you either.

I would suggest you use 1 common version(Frodo 12.2), configure a script that will do your Library update via json to every machine. Like i have 2 DBs in MySQL so i can manage individual watched status...1 is for my wife and 1 is for me( and our common shows). On each of my XBMCs, i configured 1 profile for her so any Machine she goes on, she has her watched flags and the skin she likes to use. I use NZBDrone to manage my TV shows and when a new episode is added, it sends a update to both DBs (i have 2 xbmc clients installed on my server to only receive updates for the DBs. 1 on the server and 1 in a vm on the server) Same for movies, i use a script i made with Filebot.
Image

If my replies help you, please click on my reputation Image below :) thanks :)
Reply
#6
(2013-07-30, 22:06)saitoh183 Wrote: (2) is not really a possibility since there is no way for PVR to be aware of what your other boxes are doing.

This is not true. All clients that connect to the same backend will see what recordings are scheduled. Depending on the backend you can use different credentials for certain clients which would prohibit them from changing current record schedules or scheduling new recordings.
Reply
#7
(2013-07-30, 22:18)negge Wrote:
(2013-07-30, 22:06)saitoh183 Wrote: (2) is not really a possibility since there is no way for PVR to be aware of what your other boxes are doing.

This is not true. All clients that connect to the same backend will see what recordings are scheduled. Depending on the backend you can use different credentials for certain clients which would prohibit them from changing current record schedules or scheduling new recordings.

True..true... Smile
Image

If my replies help you, please click on my reputation Image below :) thanks :)
Reply
#8
Quote:One's on pivos, one's raspberry pi, one's Frodo built from packages on an Atom/Ion box, two are Gotham builds on big linux/64 boxes.

You can actually still use MySQL in this situation. See Version table (wiki). The video DB will still be compatible, but the music DB won't be. However, your requirement for individual watch status will make this a moot point.

PVR should be "synced" by your PVR backend. There shouldn't be any need to do anything more than have each device use the same PVR backend software.

Really, it doesn't sound like you need to sync anything at all. If you need to tweak metadata and want it the same across all devices, you can use NFO files (wiki) (via multi-file export (wiki)) to keep the metadata the same. It strikes me as doubtful that you would have daily changes in that set up that would need to be copied over, or would be so drastic that it would be less work than to just individually set up as-needed.
Reply
#9
I'd second Saitoh's recommendation to use a script to roll through your remote clients and update their libraries whenever new media is available - this way each client gets to keep it's own watched and resume values, while also being up to date with new media.

I use this utility in a script that wakes remote clients if they're sleeping, updates the video library on the client, then suspends the client if it was originally sleeping. If you're only updating the library with a new tv episode, scanning just the specific tv show folder is a lot quicker than scanning the whole library.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#10
Hi all,

Lots of info to digest! Thanks :-)

Reading from above, I'm working now on making sure I understand what's stored where to only sync what makes sense.

On my master machine I do all the addon installs, configs, general- and per-profile settings. That info/data gets stored in the "/home/user/.xbmc/..." dir tree.

If I just want to (occassionally) (re-)sync/(re-)distribute those settings/addons/etc, but let each client maintain it's OWN library data & viewed state about the NFS-shared media store, what are the specific files/folders that I should sync?

I think the answer might be in the scripts mentioned above ... just started looking over what those are doing.
Reply
#11
In that case, you do NOT want to sync Database\MyVideos*.db, Database\Textures*.db or the Thumbnails folder, so exclude those files/folders from your rsync.

Then just remotely update each clients library using the tool above.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply

Logout Mark Read Team Forum Stats Members Help
Syncing multiple clients without SQL ?0