Multi Seat environment (Centralized Database) (1 Viewer)

[Gerke Grashuis]

Stupid me. It's been a while since I set it up
Re-reading the guide it occurred to me that it's not complete.
One needs to edit the MediaPortalDirs.xml in Program Files on every client that is to connect to the databases on the share.
No way MediaPortal will find it's databases by simply putting MediaPortalDirs.xml on a share in the Config dir. like the guide tells you to.
The location C:\Users\All Users\Team MediaPortal\MediaPortal (faulty named C:\Users\All Users\Team MediaPortal in the guide) is only used when upgrading MP. The location on the share is for save keeping of MediaPortalDirs.xml?!?

 

[Gerke Grashuis]

Having said that, the most important part of the guide is this: This "stike through" part does not preserve your changes when upgrading: Now from each MediaPortal PC client, you should make a backup or rename your local MediaPortalDirs.xml file (so you can roll back if problems arise) and then copy the modified file from the centralized location "Config" folder to the client PC (usually C:\Program File\Team MediaPortal\MediaPortal), and then start MediaPortal.
Reading between the lines, here it states that modifications should take place in the Program Files location in a way that MP can find its databases.

 

[Zoidberg77]

Glad you figured it out.
I tried it just once with the centralized database and promptly ran in a corrupted database...
You are very welcome to "optimize" the wiki guide

 

[Gerke Grashuis]

With a small adjustment one could prevent databases to get corrupted.
One could start MP through a batchfile.
The first client that starts MP checks if a file (e.g. INUSE.DAT) exists on the share.
If not, it creates the file and starts MP.
When it exits, it deletes the inuse file.
If, for some reason a second client tries to start MP while another is already running it, it gets refused because INUSE.DAT is already there.
Still, I do not use it so it should be build and tested.
How is that for an addition to the guide

 

[zicoz]

You're welcome.
By the way, your setup with the centralized database with former version of MP should work the same way with 1.2.3. There shouldn't be any difference at all...
Or, what I do: I maintain my databases at the server and every client just fetches the latest copy on every boot with SyncToy. Watched flags are commited with follw.it. Works like a charm.

So you have one database, and the clients have individual watched flags? Any chance you could do a writeup on that setup?

 

[Zoidberg77]

So you have one database, and the clients have individual watched flags?

No, the watchflags are alle the same. The clients have only access to a local database file which is copied from the server on every reboot. So the only way to get the "watched" flags back to server is a common interface like follw.it or trakt. I wouldn't know of any way to keep individual watched flags with a centralized database (which is somehow contradicting itself). By copying the database on every reboot I simply avoid database corruption. Draw back is that the maintenance has to be done on the server...

 

[Gerke Grashuis]

This is how I use the centralized database:
My htpc rig is dedicated for viewing movies only.
It only gets fired up when I want to view a movie. That involves firing up my lcd television, receiver and htpc.
Takes quite some time for say adding a movie to my Moving Pictures database.
That is why I moved all the MP databases to a central location on my NAS (which in fact, downloads and stores movie content too)
My laptop, which gets used every evening, is equipped with MP and Moving Pictures too and points to the same central MP databases.
Now I am able to update the Moving Pictures database whenever I want and without firing up the htpc rig.
It also gives me the ability of having a quick look at the content, to see if it stands up to my quality expectations, before adding to the database.
Concurrent use of the database(s) is, again, not supported.

Now, about the wiki describing the setup of a centralized database, I shall update that as soon time permits.
Above that, I will add a subject on a way how to prohibit concurrent use to prevent database corruption by mistake.
Maybe with some code examples too.
Again, don't use it myself so it has to be build and tested.