Open GoogleCodeExporter opened 9 years ago
That's a good idea. I think this is possible, but it would require a bit of
work. I
think if I pulled out an interface from the DatabaseManager, I could have a
separate
"database implementation" that is actually connecting remotely to another copy
of the
plug-in running on the network. This way I could keep the changes and network
logic
isolated to one place. This is a big project though, so it will probably have
to be
delayed a while. Maybe this is something we could get into a 1.0 release though.
Original comment by conrad.john
on 7 Aug 2008 at 5:37
Original comment by conrad.john
on 14 Aug 2008 at 1:01
For those anxious for multi-seat support, you can follow this guide to get
things
working on multiple systems. It theoretically could create issues with your
Moving
Pictures database, and it is not officially supported, but it's worth playing
around
with. You might be surprised, things might work very well.
http://www.team-mediaportal.com/manual/UserGuides/CentralisedDatabases
Original comment by conrad.john
on 4 Sep 2008 at 8:46
[deleted comment]
Some good discussion about this over at Issue #91
Original comment by conrad.john
on 5 Sep 2008 at 3:00
Original comment by conrad.john
on 16 Oct 2008 at 3:21
Original comment by conrad.john
on 14 Dec 2008 at 6:19
I have tried using a setup where I synced the MP database files and the thumbs
to a
shared network drive, and all users used this drive as a reference.
The problem I had was the none of the thumbs were viewable in either the
configuration nor the MP plugin itself in mediaportal. All database entries
loaded
fine, just not the thumbs/covers/fanarts.
Original comment by bjarteu...@gmail.com
on 8 Jan 2009 at 1:26
I have everything set up using the centraliseddatabases guide, but moving
pictures
simply does not work with that. It will re-scan your sources and overwrite
things in
the database.
This feature is imho way too important to wait until a 2.0 release.
Why not add the simple option of "disable scanning" so that only one of the
clients
on your network scans and alters the database and the ones that have "disable
scanning" enabled will simply read the centralised database files. Something
like
that shouldn't take to long to incorporate.
Original comment by goo...@curehyperventilation.com
on 11 Jan 2009 at 1:09
Well the Milestone 2.0 simply means that this is an on the horizon issue. We
have not
really done too much planning outside 1.0 and maybe 1.1 so 2.0 simply means
it's
sometime after 1.0.
But for this feature we are planning two phases, first phase is to just turn on
the
movie scanner in the GUI for client systems as you describe. See Issue #223.
This
will happen much sooner.
The second phase is what you see here, which would be a proper Client/Server
setup.
Original comment by conrad.john
on 11 Jan 2009 at 5:57
Issue 797 has been merged into this issue.
Original comment by travistx
on 10 Mar 2010 at 6:44
The multi-seat solution should leave local copies of fanart/coverart on the
clients,
otherwise browsing will be too slow, I am afraid - degrading the user
experience of the
GUI.
Original comment by jacob.ba...@gmail.com
on 15 Mar 2010 at 8:36
Original comment by conrad.john
on 31 Jan 2011 at 1:23
This is going to sound really really stupid but my preferred solution would be
you have a central/master database on a/the server which is synced using
mysql's own tools for the job
(http://forums.mysql.com/read.php?27,216438,216438#msg-216438)
with the clients being slaves including the one box
Data is sent from the server to the clients about the films i.e. file A is Film
A etc
You can have an option to update the server from the client -for watched data
etc
If you are sharing directories you put the paths in as the shares i.e.
\\<server>\<share> when working on the server that way Moving pictures can
easily pull up the films
As to fan art etc - option to cache this would be ok or just store it in the
database
Original comment by alister....@gmail.com
on 18 Feb 2011 at 1:05
i like the idea of being able to use different implementations for the database.
This might be just one specific scenario, but i could imagine many similar that
would be easier solved with a different database implementation:
i maintain a webpage (php/mysql) with all the information about my movies.
moving pictures fetches that info with a custom scraper. This setup is limited,
as moving pictures still has to look at the share folders, detect the movie,
match it with the webpage etc.
You can't just add a movie to the webpage and see it in mediaportal - actually
i'm still looking for a simple way to list all my DVDs that are listed on the
webpage but are not in the share folder. Another issues is, currently i have to
maintain the watched flags on the webpage by hand, as there is no way to report
that automatically.
Having an interface to the database, i could just implement a simple bridge to
the webpage and use that as my database server. Or if the interface of the
server would allow, have the webpage use the database server as well...
Original comment by chrisdra...@gmail.com
on 18 Feb 2011 at 3:49
Chris, you should checkout http://follw.it. It has full integration with Moving
Pictures and does what you are asking for.
Original comment by conrad.john
on 18 Feb 2011 at 4:06
The way I see this feature working is to have a master database which is
updated by a service which monitors the movie folder(s). All the clients just
sync to that database and copy any images to a local cache to improve user
experience. Having a separate monitoring service means I don't have to go into
the "master" client to get the updates done.
This fits well with my particular setup as I have server performing TV duties
with all my movies/other media on a Drobo.
The ideal would be to have a system similar to the way the TV plugin works, so
all I need to do on the client is tell it where the server is. The config could
then be pulled from the server behind-the-scenes.
I am a software developer by trade, so would be happy to help out developing
this feature.
Original comment by scott.an...@gmail.com
on 18 Oct 2011 at 12:31
Original issue reported on code.google.com by
pira...@gmail.com
on 7 Aug 2008 at 5:06