Centralized Database; LAN?

[MrPixar]

Heya --

I've seen this mentioned in other posts, but did not see a specific wishlist item for it, so here goes...

I would love love LOVE the ability to make use of MM in a LAN configuration. By this I mean 1 database, and multiple clients. I know I can share the physical library (music files), but each MM has to have its own database. What I want is a single database (meaning support for DBName=UNCPath in the ini file as well as the ability to determine file paths over the LAN). Currently, I have been able to "share" the databse over the LAN, but as soon as the networked client tried to play something, of course, the filepath is oncorrect for the music file.

Please please PLEASE!?

[Teknojnky]

You can specify a central database file by modifying the mediamonkey ini file.

Code: Select all

[System]
DBName=j:\program files\mediamonkey\MediaMonkey.mdb

Where obviously I use J as a mapped drive/external hard drive for mediamonkey and also keep my music collection on J: as well, this way I don't have to deal with any issues (if any) regarding differing paths for the same file.

[MrPixar]

you cannot currently specify the path the way I am proposing. i.e.

Code: Select all

DBName=\\Server\Path\To\MDB

On the secondary machine because if you open it and try to play a song, the song path is inaccessible (it's local to the first MM installtion)

I've tried to do it, and was met with the error of selecting a track and having MM scroll (quickly) through my entire library as inaccessible

Besides, MM does not currently support multiple MM installations sharing a single DB (which is what I am wishlisting)

But thanks

[Teknojnky]

It does seem to somewhat support it, if you have everything mapped to the same drive letter.

But, I would definately like to see your suggestion get implemented, getting things setup via UNC paths is more elegant and flexible.

[Teunis]

I have MM working in a LAN-configuration. Specifying the database location using UNC-path notation is no problem.

You can solve the drive letter problem by making all references in the MM-database UNC-based. E.g. in my database all music located on the musicserver's D:\Music\etc is listed in the database as \\SERVER\D\Music\etc

This makes the music accessible both from the local server and from any client.

[Balinsky]

My database is on my Lan as well if your tracks are inaccesible you just have to rescan them using the network location for the files as well.

Yes you will lose all your play count and such. But If I am right you are new so it shouldn't be that bad. It made me mad when I had to do it as well.

[m_bojangles]

I really want to do this so that I can access, listen to and synch music on both the upstairs PC (where my wife's Zen Micro is) and my downstairs PC (where my Archos is). Trouble is... I've been using MM for years, have 30,000 tracks and can't afford to lose my playcounts, ratings, datestamp for adding to the library (my backup scheme is based off of this) and other metadata. So can the paths be updated via a direct Update query in MS Access?

[m_bojangles]

I really want to do this so that I can access, listen to and synch music on both the upstairs PC (where my wife's Zen Micro is) and my downstairs PC (where my Archos is). Trouble is... I've been using MM for years, have 30,000 tracks and can't afford to lose my playcounts, ratings, datestamp for adding to the library (my backup scheme is based off of this) and other metadata. So can the paths be updated via a direct Update query in MS Access?

[pierre]

m_bojangles: There's probably no need to use Access... Have you tried auto-organize (Ctrl-R) of the files ? There are special <Folder> and <Path> fields that might help you in this case : try a mask like

Code: Select all

\\ServerName\<Path>

You can also use <Path:2> if you don't want to include the 2 first folders of your path... See MM help !

Anyway, it is still not sufficient for a completely shared library, because when a MM instance updates the DB, the other one(s) have to be aware of the update. So I agree : would be great to have it implemented !

[Teknojnky]

Anyway, it is still not sufficient for a completely shared library, because when a MM instance updates the DB, the other one(s) have to be aware of the update. So I agree : would be great to have it implemented !

Watched folders works well for this. I've modified the library/files from remote computers while having MM open on a different computer (using a network shared installation/library) and it works fine for me.

[task]

I see a better solution for an centralized database than working with
with hardcoded paths in an .ini-file.

My suggestion is to have an real Client/Server-solution like it is implemented in professional database applications.

For example:
1. The database is stored on the server.
2. On the Server a daemon (process) is running which has access to the
database and listens to a specific tcp/ip-Port on the network.
3. On the Client, mediamonkey is startet and makes a connection to the
server-daemon (over the tcp/ip-port from the server).
4. Now the client gets all the information it needs from the server, including
the music-files (could be the same port or a different).

The client-modul (Mediamonkey) could also be startet at the server.
This is needed if you have only one system. The communication over the
port will be the same.

Additionally this could be expanded by:
A. Userspecific configurations:
The user has to authorize in the mediamonkey-db when he starts
the client-modul. That means you have to specify a username/password
and the ip-address/portnummer of your db-server.
Then you get your userspecific view to the database including
your playlists and setups which are stored in the database.
This will also work over internet!!!
B. Configuration whether to use the local (client) soundcard or the
remote (server) soundcard.

think about this for discussion. This is not new. I used a similiar system for
some years ( www.andantico.de). Unfortunately there is no further
development any more so I decided to go for Mediamonkey.
It has also a working prelisten-funtionality.

One thing will possibly not be available, that is the connection to winamp
including all the winamp-plugins. But maybee there could be written a
special mediamonkey-winamp-interface.

[Peke]

I support that kind of idea, something similar I have managed with warious Plugins and Winamp ~5 ago Years over 10 Base-T LAN it is matter only on setting of Winamp Plugins LAN managment (WinGate at that timewith Per user access) and all worked Like a charm. Now With S-Ata Raid HDDs 1Gb Lan (100Mbit per client) everything can be made, only part That needs to be done is SQL <-> MM Lib calls needs to be made and all will work great Even searches all thru Burning from Filee server will be still tricky.

[ManMachine]

I really would like to have a more sophisticated way to have a centralized DB.

My DB is 5 years old and it always worked centralized. Every computer at home uses MM with centralized DB.

The current solution to centralize the DB requires a lot of patience due to performance and and connection errors. I can tell a lot about the difficulties on keeping my central database alive over all these years. Actually if it wasn't for the problems I have learned to overcome my DB would be even older.
Example: When the network connection fails MM produces SQL errors which in most of the cases result on having to kill MediaMonkey.exe with the task manager. Sometimes MM even proposes to create a new DB! That's the scariest thing because if you say yes and the connection is back MM will replace your DB by a blank one (horror!!!) That's what made me start again 5 years ago. I have implemented redundant backup systems for my DB. It's my biggest asset. The collection can be rebuild but not the listening history.
With a DB of that age I can program intelligent lists proposing least or most listened songs of my 80000 song collection. The statistics I can get are amazing.

[Lowlander]

That's the scariest thing because if you say yes and the connection is back MM will replace your DB by a blank one (horror!!!)

That's not true, the old DB will still be there. Instead MediaMonkey will use a new blank DB in the default location. Just re-adding the DBName database redirect with MediaMonkey closed will resolve this. Also it asked to create a new DB and you've said yes to that.

SQLite doesn't work well in a shared environment, however this only is an issue if you need multiple write access to the database. If you only require read access from all but one PC you can use the Media Server instead to share your media. I use this setup to share my Library among PCs, smartphones and smartTVs/Blu-Ray and it works wonders. The only performance issue (SQL errrors) I run into has been written off to overly complex AutoPlaylists), but I'm still using my 11 year old DB. That's despite using many of the beta releases. Of course I do backup the database daily and also do weekly sequential backups. But that's what many do with important files on their PC.

Now I personally do hope they go for a better database provider for MediaMonkey 5, with my personal preference leaning to SQL Server.

[CCS86]

I have been hoping for this forever!