Provide posibility to use remote content DB (1 Viewer)

[rivera]

Currently, the mediafiles' info DB is located on the same computer where MP is installed.
But if I have two or more HTPC at home, I prefer to have only ONE database.

As far I uderstood there are 3 types of potentially shareable information:
1. Mediafiles themselves - this can be solved easily by selecting remote shares.
2. Mediafiles databases - are placed in "database" directory locally.
3. Thumbnails for movies, albums etc - are placed in "thumbs" directory locally.

I propose to provide in "MediaPortal Configuration" two options:
- either to keep databases & thumbs locally
- or to attach to already created resources on some specified network path

 

[tourettes]

Won't happen with Mediaportal 1, instead MediaPortal II is already designed in that way.

 

[kirill_mmm]

Won't happen with Mediaportal 1, instead MediaPortal II is already designed in that way.

I can implement using of remote database via plugin, but for this some little enhancement in DatabaseFactory class is needed. The idea is to check in method GetVideoDatabase() before instantiating VideoDatabaseSqlLite class if some setting in MediaPortal.xml, for example VideoDatabaseClass, exists. And if it exists, instantiate this class instead of VideoDatabaseSqlLite. Is it possible?

 

[Bagal]

See the documentation on Centralised Databases which will enable you to use a single database for all your clients.
Note however that this isn't officially supported and there are potential issues with it but many forum members including myself use this technique successfully.

 

[kirill_mmm]

See the documentation on Centralised Databases which will enable you to use a single database for all your clients.
Note however that this isn't officially supported and there are potential issues with it but many forum members including myself use this technique successfully.

Thanx, but I've already seen it. It's not the right way to use a single database for several MedeaPortal's instances. The right way is using one entry point on database for all instances. I want to write plugin wich will replace database provider in MediaPortal with the one supports remoting. Actually, the possibility of replacing database provider exists in MediaPortal, but now it's hardcoded to use internal provider. I just ask to make this possibility work.

 

[LordMerlin]

Sorry for my English, so how I see the potential for a network media server and multiple clients:
1. If Mediaportal not retain their data in different databases in the form of files, for example in a single database running on MSSQL or MySQL. These projects would provide equal opportunity to connect to a shared database on a network without any conflicts.
2. Folders with thumbnail and fanart can be made available on the network itself, and that the server and clients turned to them on the network paths in order to avoid conflicts between the subsystem and the local network access.
3. With the single database server, you can easily use any engine web server to make online access to its database of music films and photos via the Internet with the possibility to edit the descriptions of loading and downloading files. Similar access mechanism is implemented in Windows Home Server.
4. Having a common base, you can easily make backup of all data to facilitate subsequent recovery from failure. Its even possible to make an automatic means of the engine databases.

If I'm not careful, the MSSQL database in general, you can keep the cover and other data.

 

[Bagal]

Thanx, but I've already seen it. It's not the right way to use a single database for several MedeaPortal's instances. The right way is using one entry point on database for all instances. I want to write plugin wich will replace database provider in MediaPortal with the one supports remoting. Actually, the possibility of replacing database provider exists in MediaPortal, but now it's hardcoded to use internal provider. I just ask to make this possibility work.

I agree that it's not the correct way to do it but as an interim solution it works and as tourettes said, MP 2 has been designed in the correct way already.

I think your idea is a good one but at the moment I really don't see the point in putting in a lot of effort to do this for MP1 when the long term goal is to move to MP2, not that I wouldn't like to see it implemented of course!