MP2, plugins, and multiple clients. (1 Viewer)

[craige1]

Hello MP2 team,

As a plugin developer, I was wondering if MP2 will have any inbuilt support for sharing plugin configuration and databases, to help with multiple client setups?

 

[Albert]

AW: MP2, plugins, and multiple clients.

It's not planned to have inbuilt support for that. The strategy is not to have so many configuration options. Most of the options should be local for the client, e.g. the location of local shares, if the application should be shown fullscreen etc.
If there will be areas with many options which make sense to be shared for multiple clients, we can develop a solution.

 

[funkstar]

I had hoped that there would be more scope in MP2 for settings and options to be pushed out from the server or pulled from it by the client.

 

[infinite.loop]

craige1, do you mean that the user only has to configure the plugin on one HTPC, and then is able to copy this configuration to all the other clients? Thats something I proposed on the Team already.

Maybe even "clone" an entire MP2 installation from one (template) HTPC to another including all skins/plugins/config/etc. That would be nice.

Regarding the "shared db".
Good question how plugins like MovingPictures and TvSeries should work on a multiseat MP2 setup.
Best would be if the developers of such MP1 plugins would take a look at the MP2 system and then share their thoughts about it.

 

[Mike Lowrey]

As most users with multiseat setup are using the tv server, it should be possible to use the backend databse of a server component to store things like media paths, same could be done with all kinds of settings if the plugin developers try to abstract the settings from client specific things.

For example if a plugin uses a different resolution, it should not save the plain resolution, but the multiplier which represents the difference of the plugin resolution and the global windows resolution.

 

[Mouch.net]

Regarding the "shared db".
Good question how plugins like MovingPictures and TvSeries should work on a multiseat MP2 setup.
Best would be if the developers of such MP1 plugins would take a look at the MP2 system and then share their thoughts about it.

Wouldn't a Client/Server split for those plugins be the best solution too?
I'mean... the client should only retreive the available Movies/Series info from Server...
And Server will do the whole scanning, scrapping, analysing part and maintain the Movies/Series DB.

 

[Gixxer]

iloop i agree.

my way of thinking is that in a multiseat environment, only one setup should be done.

rest of the clients should find the server, and ask to import all setup options.

then user can adjust some options for every client in case needed.

but, things such as the following should be shared straight away.
tv and radio logos (like FTR does)
shares paths
movingpics, tvseries etc thumbs, covers, etc
database info (moving pics, tvseries etc)
etc

 

[craige1]

From what I understand so far of the MP2 "way", the medialibrary is where the shares and releated media info should be stored, and the database engine should be used for databases.

I understand that the medialibrary is available to all clients. That will make sharing media across clients easy for plugins. (on a side note: it should also make finding media from plugins easy to find for other plugins, eg, a burner plugin should easily be able to find all media in the moving pictures or tv series plugins).

I assume that the database engine is also available to all clients.

So it seems like media and databases for plugins should be easy to do in a multiclient setup. The last 2 things plugins use are images/thumbs, and the config files(xml files in MP1).

If images are counted as "media" according to the medialibrary, then these also will be easy to use in a multiclient setup, but I dont think they are. I also dont see anything to share config options.

I really do think there should be a way of easily sharing images across clients. I know my current image folder is roughly 1.5GB, for just 1 client. Times that by the amount of clients and it can really add up. Also consider nearly all the images are downloaded. A built-in way could really save MP users, time, download quota, and setup difficulty. It would also help with plugin developent time and allow plugins that deal with images to easy find images for other plugins.

A builtin way to share configs will help MP users with setup, and help with plugin developement. I do know with our plugin that there are options that are generic to all instances of the plugin, and im sure there is the same situation with other plugins aswell.

The two other things i would like to know are;
1. Does the MessaegBroker work across clients.
2. Is there a way to find out about the other clients. E.G, a list of clients, what there performance is like, available HDD space, etc..

 

[Albert]

AW: Re: MP2, plugins, and multiple clients.

Hi craige and sorry for the late reply.

From what I understand so far of the MP2 "way", the medialibrary is where the shares and releated media info should be stored, and the database engine should be used for databases.

Shares are properties which belong to each computer in the MediaPortal 2 network. Shares can be defined on clients as well as on the server. When a share is defined on the server, the share dataset is stored directly in the media library database. When a share is defined on a client, in the first place, it is stored in the configuration settings of that client.
As long as the client remains detached from MP2 servers, the local configuration setting is the only place where the data about the client's shares is stored. When the client attaches to an MP2 server, that server becomes the "home server" for the client. At this time and at each future connection time, the client synchronizes its shares datasets with the server. The data about all server shares as well as the data of all client shares are stored in the server's media library.
(Under certain circumstances, it is possible to edit the client's shares even if its home server is offline. In that case, the automatic shares synchronization updates the server shares the next time when it is connected. So the shares information on the server about client shares is always up to date.)

When a share is defined in the server's media library, the local importer worker instance tries to extract metadata from that share. The importer workers run on each system where shares are defined. They import as many metadata as they are able to during connection time. When the connection to the server goes down, they remember their current progress and restart at that position the next time.

During the metadata extraction, media item metadata datasets are stored in the server's media library.


The database engine is a system service available at the server. Only server plugins are able to use the database engine directly. The media library is based on it; it uses SQL statements directly to store its media items and shares data in the global database.

There is no client interface to the system's database (yet); IF a client wanted to store data in the database, there must be a corresponding server plugin which stores the client's data in the database. Those two plugins would communicate via UPnP, using the extendible UPnP interface (client as well as server would attach new UPnP services to the main UPnP device for communication).

I understand that the medialibrary is available to all clients. That will make sharing media across clients easy for plugins. (on a side note: it should also make finding media from plugins easy to find for other plugins, eg, a burner plugin should easily be able to find all media in the moving pictures or tv series plugins).

Each plugin on the server can access the media library with all of its public methods directly. Plugins at the client can access the media library via its UPnP interface which provides access to almost each native method.
Methods of the media library include shares management, media items management, media items query, media item aspects management and client management. From those, only the media items query and sometimes media items management methods should be called from plugins. The other parts are system parts and should not be accessed by clients directly.

I assume that the database engine is also available to all clients.

As I already said, that is not the case. Clients should store local settings as local configuration settings (via ISettingsManager). Until now, there was no real reason to build a global settings interface for clients at the central server. But if that becomes necessary in the future, we might add such an interface.

So it seems like media and databases for plugins should be easy to do in a multiclient setup. The last 2 things plugins use are images/thumbs, and the config files(xml files in MP1).

• Media items are simple to access for client plugins
• Database access is not opened for client plugins as it is only available on the server
• Settings can be stored via the ISettingsManager API
• Image management - see next part

If images are counted as "media" according to the medialibrary, then these also will be easy to use in a multiclient setup, but I dont think they are. I also dont see anything to share config options.

Images, which are located in shares (which are marked to contain images), are scanned the same as video and audio files. Image metadata is stored in the PictureAspect of media items, video metadata is stored in the VideoAspect and audio metadata is stored in the AudioAspect. Here comes our very extendible metadata storage into play: Each media item can have as many attached media item aspects as necessary. A media item aspect is like a table with attached attributes. There are some default aspects available: MediaAspect (containing general media metadata), VideoAspect (containing metadata for videos), AudioAspect (containing metadata for audio), PictureAspect (containing metadata for pictures), ImporterAspect (containing data about that item for the importer) and ProviderResourceAspect (containing metadata about the storage location of that item). See our wiki description about the media management subsystem.

Also consider nearly all the images are downloaded. A built-in way could really save MP users, time, download quota, and setup difficulty. It would also help with plugin developent time and allow plugins that deal with images to easy find images for other plugins.

Which kind of download are you referring to? Download of images/media items from their original storage location inside the MP2 system or download from a remote location somewhere in the internet?

The media access of remote media items which are located at some host inside the MP2 network (at the server or at some client attached to the same MP2 home server) is very easy. It is not completely implemented yet but at the end, you can simply use the media access API to get either a stream access to any remote media item or even to get access to a remote item which seems to be located locally. We do that by temporarily attaching a local filesystem via a filesystem driver. In that temporary filesystem, we show those remote media items which were requested to be locally available. Internally, we have an open network stream to the computer where the item is physically located. That is like accessing a remote file vial the UNC protocol in the windows explorer.

A builtin way to share configs will help MP users with setup, and help with plugin developement. I do know with our plugin that there are options that are generic to all instances of the plugin, and im sure there is the same situation with other plugins aswell.

Which kind of options? Tell me an example please.

The two other things i would like to know are;
1. Does the MessaegBroker work across clients.

No, it doesn't.

2. Is there a way to find out about the other clients. E.G, a list of clients, what there performance is like, available HDD space, etc..

The media library and the client management UPnP services at the server contain methods to see other attached clients and their current online state. The media library supports filtering of returned media items by the online state of the native client.

Currently, there is no API to get system information about other clients, neither for server plugins nor for client plugins. But - as with other system parts - if that is really necessary, it is easy to add such an API. You only have to convince me that this is really necessary ;-)

Cheers,
Albert

 

[infinite.loop]

Re: AW: Re: MP2, plugins, and multiple clients.

2. Is there a way to find out about the other clients. E.G, a list of clients, what there performance is like, available HDD space, etc..

The media library and the client management UPnP services at the server contain methods to see other attached clients and their current online state. The media library supports filtering of returned media items by the online state of the native client.

Currently, there is no API to get system information about other clients, neither for server plugins nor for client plugins. But - as with other system parts - if that is really necessary, it is easy to add such an API. You only have to convince me that this is really necessary ;-)

We need at least an way to alert the user when he is about to run out of free disc space on the HDD he is recording TV Shows/Movies to (and where TsBuffer is stored).