multi-seat plugin - how should it work? (1 Viewer)

[JonJon]

Hey all,

I was wondering if I could get some feedback on how you think a multi-seat version of the plugin should work. Some specific areas of interest are:

• Watch Status - toggled per client or global
• Network share or Streaming - Is having a network share acceptable or should it be streamed to the client
• Local sources - Did you want to include removable sources like DVDs that are accessible by online the current client
• Pincode protection - Is pincode protection per client or global
• Series list - per client or global

If you can think of other issues we that should be considered, mention them as well.

 

[Surferosa]

Im currently running 4 client versions of MP. Right now, I get round the whole multi-seat issue by having two local database copies (ie 1 for each client), and 2 using the multi-seat hack (on the basis that I only ever use 1 at a time). Multi-seat is the next big step forward for MP for me: and on the basis that noone responded yet- I'll give you some input...

* Watch Status - toggled per client or global
EIther/ configurable per client if possible. Rationale is that for me and the wife, we would like to see the watched status wherever we use MP. The kids have a totally different schedule- so they would view on a per client basis.
* Network share or Streaming - Is having a network share acceptable or should it be streamed to the client
For me, Network Share is fine (all mine is streamed from a nas).
* Local sources - Did you want to include removable sources like DVDs that are accessible by online the current client
For me, no- DVD sources can stay local.
* Pincode protection - Is pincode protection per client or global
It would make sense that these are global (to me at least) otherwise we could potentially override the pincode locally. Then again, thats more an issue that you can't lock-down a configuration setting (ie anyone can change the pincode in the config)
* Series list - per client or global
The filters are key here. The way the Moving Pictures 1.0 Beta allows you to filter out restricted content is perfect (so on films, the kids only see listed the films that I have provided as unrestricted). As soon as the unrestructed pincode option is put in, I can see them all. Works a treat (meaning it works fine either globally or locally).

 

[RoChess]

There are also different ways the multi-seat could be implemented.

1. Server-Client based. All clients connect to a mutual server to locate the database, so they all share the same, each client is aware that others might be modifying the database, so the clients must LOCK tables and such before modifying and poll/push/refresh for changes made by others.

2. Each client keeps their own database, but a seperate 'sync' plugin runs in the background to communicate with all the other clients on the network. This could also involve a server that contains the main database, but each client relies on their local database for their actual function.

The benefit of #2 is that when the network is down you can still use MediaPortal and all the plugins as if nothing has changed. This would be beneficial for those users who have a small portable HTPC client and would like to take that with them on the road. Of course it is also possible to add a local-export option for the #1 server-client method, I just hope the developers are aware that such functionality might be handy then to incorporate.

Staying with method #2, I think this method would have the benefit that it will be easy to make it global. As in not make it work for just MP-TVSeries, but also for MediaPortal itself as well as other database plugins such as MovingPictures. The only change to the 'sync plugin' would be understanding of their database structure (XML file maybe?) so that the right information can be synced.

The syncing itself could be split in multiple levels. This is because I think the main goals for syncing to begin with are the adding/removal of shows via their physical files and the data maintained regarding the file, such as plot/watched-status/etc. Since there is no mutual server allowing for a 'lock' on the file/dbase, it would have to become an extra setting inside the configuration to decide which HTPC-client is the one to fetch all the information from thetvdb.com, all the other clients detect the presence of a new file the same way they are doing now, but instead of fetching the information from thetvdb.com they keep polling the main HTPC-client to see if they are done yet so that they can duplicate the information.

It's not that easy alone, because the location of the file could be different. Unless all files are stored on a mutual NAS for all clients to use, then there is no problem, but the "D:\TV" folder on the HTPC-client doing the internet lookup would have to be modified into "\\UNC-PATH\TV" for the clients syncing that data over. This shouldn't require that much extra code, because the clients that are syncing are already aware of the different location, because the existing routine to sense a new file has been detected would have to already be aware of this location, and it can then simply do a filename matchup with the main client.

As for syncing the rest, the sync-plugin could maintain a seperate database with a copy of all the changes made to the main database with some added fields (UNC timestamps/etc). This could even be done via XML files that are stored on a mutual location that all the HTPC clients have write access on. And all each client has to do is fetch the XML files not created by itself and integrate that in their own database. Once done it would either modify the same XML file to indicate that it has completed processing or create an extra file. Then all that is needed is a cleanup process on the main HTPC client that verifies on intervalls that all the clients have processed a certain file and delete them all. If client A updates something and tv-episode.xml has been made and client B fetches this info and somebody on that computer decides to make extra changes, then it simply has to update the tv-episode.xml file (after it verifies no lock file exists from another user, because the lock files need to be created before the XML file is made) and then it simply creates a lock file for itself, removes the lock-file from client A, modifies the XML file and everything will be good. Because at that point client A recognizes that it doesn't have a lock-file on the XML file still present, so it begins the same update process. This will also prevent client C from missing out on both changes made by A+B if it gets turned on later.

The more I think about this (I'm just spewing thoughts here), it might be best to do this via a mutual database, because the "locking" part is much better integrated inside a database engine, with support for those rare situations in which 2 clients would start an update at the exact same time and risk of a dead-lock.

So that's my 2 cents. I highly doubt most of what I said will be useful for the final solution, but a discussion doesn't hurt to prevent any pittfalls.

 

[JonJon]

Thank you both for responding, I've got some follow-up questions for you!

1. How would you define a client? A machine or a user. The reason I ask is that if I was to make the toggle status per client the definition would determine if I use a local database for storage or not. If its by user then it would require the user to login (just a pincode?) but they would be able to use their configuration and setting on any machine.

2. Is a restricted/locked mode and unrestricted mode preferred to the above? i.e. all clients will run in a restricted view mode (filter out content by classification?) until the pincode is entered and then everything is available.

3. If we are going to have watch status per client then what else should be? Views?

4. Would you prefer to have the plugin watching shared folders and import to a central location(repository) or as it currently is. This is mostly for ppl that download/rip episodes on a different computer and would allow some nice file name formatting when importing.

I'll give you a brief outline of how I see this working, let me know if you see any faults or enhancements.

A windows service will run on your server, this will handle all the back-end processing of the current plugin, that is watching for new files to import, downloading tv series info and images from thetvdb.com. It will have either an SqLite, MS SQL or MySQL database that stores the global configurations.

Clients will query the service using network protocols and access episodes via UNC paths (Shared Folder/s). Images will be cached locally, although I am tossing up if this should be configurable but not sure what the impact of responsiveness will be like if clients access images directly. They may also have a SqLite database for local configuration and status should we go the route of per client settings.

 

[spar1grep]

Designing My TV Series to use a multi-seat configuration would be ideal as I have a three node configuration for MP all of the nodes use the My TV Series plugin by pointing them all to use the same database file on a shared folder on the TV Server. However as I am sure you know it does not work very well due to the locking of the entire database by a node at any one time (which is not always consistent it happens once a week maybe), resulting in MP taking over 10 minutes to attempt to load the My TV Series plugin (when another node has the file locked) before it fails. You can tell when it fails if you have configured the plug-in to display a different name then when the plug-in fails the initialise if displays the default My TV Series name in the MP home screen.

Im not too sure about the extent of which the possible solutions being muted is needed (please dont take offense as you know your plug-ins complications in terms of code better then me). If your application code uses SQL to create/modify the records stored in the current database can you not just allow for the configuration of a ODBC based data source? Then most of the locking issues are resolved for you.

As for having some form of designated master plug-in and the rest client plug-ins in a multi-seat configuration for My TV Series, my configuration works well as is, in that all the nodes are configured to use a mapped network drive for the database location. The folder being watched is also on the same mapped network drive. I have never (in the 12 months plus I have been using this configuration) ran into a issue where say for example whilst the plug-in is watching the mapped drive where the episodes are stored that if two nodes are running that they both try to update the database with the same information causing corruption/problems. I put this down to some form of logic in your code where if a new file appears your code first checks to make sure the episode related to the does not already exist in the database, the chances of two plug-in clients watching the same folder processing the same new file detected at exactly the same second/millisecond is remote (not to say it should be ignored).

In relation to the fanart/logos, I figured out where they where stored and just copied them across to all nodes from the central node as it appears that the logic in your code once the database has been updated with the fanart/logos file names for the files downloaded does not check to see if they still exist. The best route I see here is to allow for the re-configuration of the path (in the same manner that you do the database) where the fanart/logos are stored.

 

[MrLobster]

My limited knowledge in DB access leads me to think this...

Using Apache+MySQL you dont need to lock any tables as apache will handle each db call individually. The only problem with this is when 2 identical requests happen at the same time, but this just means that the client and server might be out of sync (until updated), but that may happen if you lock the tables anyway.

So the major problem with multi-seat is making sure that all clients (users or PC's) are synced to the DB.

 

[JonJon]

spar1grep

I'm not an expert in ODBC, but I believe in regards to .NET its use is discouraged and other managed technologies promoted. On the more technical side, I'm not sure where the locking is occurring it could be at the database level in which case I do not think ODBC would help or it could be at the .NET data provider in which case the ODBC driver manager might help with concurrency. Since your post I've done a little checking on the availability of ODBC drivers for SQLite and a third-party is available. For drivers I would prefer if they were first party rather then third party but perhaps someone could get the plugin to work with ODBC down the road. The Service version of the plugin wont however.

We'll first try a shared folder for images that all clients can grab from, however if ppl do experience problems then I guess we'll just have to cache them locally.

MrLobster
Databases generally handle the locking, usually by table or row. As for syncing problems I agree this is an issue that we need to be aware of but I think they will only be noticeable if you remain on a list screen for a long period as screen information is dynamically loaded and I have some ideas on how to keep it closely synced without a lot of polling. Wont now how well it will work until its implemented though.

------

After some more thought in regards to clients and pincodes and all that, I've come up with the following:

- The current pincode will become the Master pincode and will lock the configuration (can leave it unlocked).
- Each machine will be a client and will be able to set a pincode.
- A client can run in one of two modes:
- Restricted: Can only view a subset of series, limited either by Classification or manually set
- Unrestricted: Can view all series
- A Client will have its own watch status and bookmark for episodes, can set up views that are only available for the client

Have I forgotten anything? Is there a behaviour you'd like it to have?

 

[robinandrogyn]

Hi,

I am not sure if this is what you are looking for, but this is how we would like to use MP in our family:

We all buy DVD"s and watch them in the lounge. Sometimes alone, sometimes with more. Some DVD"s will not be watch by everybody or different people in different sessions.

I would like to see functionality where we can track who has seen what (or who has NOT seen what).

One approach could be to let someone log in and let the plugin track what is being watched automatically, but should still be able to change the "viewed" state for another user.

R

 

[jsimmons]

Viewed Status

Realistically, most people will probably watch something in one room, and something else in another. Logically, that dictates that the "viewed" status would be most useful as a global status. However, it wouldn't be a hard thing to actually log the IP (or MAC) address (or even the actual machine name) of the viewing machine in the database, so that a machine could report/react to its own viewing history, or the viewing history of a given show could be viewed on any other machine.

Share vs Streaming

I assume you're talking about the video itself. In that case, it should be up to the user.

If you're talking about the database, the user should be able to specify WHERE to look for the database (local box, network share, or even a web site). Of course this means that all video paths stored in the database would have to be UNC paths so that the path resolves the same way for all clients.


Removable Sources

That should be a config setting. Default would be to NOT include removable sources

PIN Code

They should be specific to each video location. Just because the video is on another ox doesn't necessarily mean everyone should have the PIN for it.

Series List

It should be contained in the database. Period. All machines would get the series list from the central (one and only) DB.

------

One thing that might be useful is a way to lock out other machines from viewing content stored on your box. Just because a movie is on a locally accessible share doesn't necessarily mean that everyone should be able to view it.

 

[zicoz]

Viewed Status
Realistically, most people will probably watch something in one room, and something else in another. Logically, that dictates that the "viewed" status would be most useful as a global status. However, it wouldn't be a hard thing to actually log the IP (or MAC) address (or even the actual machine name) of the viewing machine in the database, so that a machine could report/react to its own viewing history, or the viewing history of a given show could be viewed on any other machine.

I have to disagree here. Many "MP-admins" have multiple users in their household, and having global viewed status would really create a mess in those households.

- Let's say the father of the house watches an episode of Fringe on the HTPC in the living room.
- The next day the son starts My TVSeries on the HTPC in his room, and then the episode is watched on that HTPC aswell.

I agree that both global and local has pros and cons, but imo this problem trumps it.

The only way I can see that fixes all problems is to implement a usersystem, but that is probably alot more work. A "quick-fix" though would be to have a setting where people could choose if they wanted global or local tags.