MediaMonkey forum

You should be able to directly access the DB, however you'll have to content with some customization that MediaMonkey did as Peke mentioned.

I agree that some sort of multi-user database is the way MM should go and it would deeply improve my satisfaction with the product.

• UPnP is a terrible user experience
• I don't want to sync 30GB of data to my portable devices when I could just stream it over the network! (MediaMonkey Sync seems to only support downloading the content locally)
• I want one library of playlists, ratings, and playcounts on my home network.
• A multi-user SQLite database works for about two hours and then gets corrupted. Those were a glorious two hours though!

I have searched high and low for a product that can meet these requirements and none exists, but MediaMonkey seems to be the closest.

How is UPnP terrible? (it is also the way to stream to your devices on the network)

1) Magic Nodes can be used to create a custom navigation: http://www.mediamonkey.com/forum/viewto ... agic+nodes
2) This is planned for the future, MMW supports is server side so any App that supports it can be used
3) DLNA/UPnP doesn't support this, nothing MediaMonkey can do about this
4) DLNA/UPnP is limited in the fields it support. For me this isn't a problem as what I want to play is determined by AutoPlaylists in the server and Play History is maintained for UPnP plays.

I would like to see media Monkey have an OS, instead of using a freenas type OS.

Yes, please use something that will allow reliable sharing of the database over a network between multiple desktop instances. I had to stop using MM a while ago because I experienced database corruption when trying to share the database.

Speaking as a scripter who uses direct SQL in a number of his scripts, having different database formats could be a bit of a nightmare, as you'd have to write different sets of SQL as well!

trixmoto wrote:Speaking as a scripter who uses direct SQL in a number of his scripts, having different database formats could be a bit of a nightmare, as you'd have to write different sets of SQL as well!

If they kept the same database structure/schema, then most likely you wouldn't have to change your scripts.

You would, the commands in SQLite are different, I remember when MM changed from Access to SQLite and it took me quite a while to update my scripts, and I've got a lot more now, and less time to update them!

Other than a few special functions, the command syntax is the same with SQLite and MS SQL. They both are based on SQL unlike Access.

There are several databases on the market and it would be great to be independent from a special SQL syntax. So what about an API (SOAP, REST)? I think the implementation would be a lot more easier than a DBAL. Together with a good documentation this would be my favorit solution.

As a long time user of media Monkey, this is the feature that keeps me checking other applications. I have a shared MM.DB file, and it works. But if two people have it open, it's horribly slow. And running over a vpn? Unusable.

This said, I understand the difficulty of writing for a new database (even though there seems to be a ton of support suggesting such an effort is worthwhile). Perhaps this is worse, but if you provided (sold even, I'd pay for it separately) a MediaMonkey server that the clients connected to this system would be perfect. Obviously, the scripting/api support would be extended here. (Of course, if it ran on Linux, the pure awesome would be hard to contain )

But please, please...move to client server in some format. MySQL is awesome (MariaDB probably a better place as Oracle defiles MySQL), Postgress, something open. Or a MediaMonkey server app. Please.

An MM Server already exists in the form of a UPNP (DLNA) server. It allows you to access anything you share, however no tagging/updating as DLNA doesn't support this. It can even be run as a service in Windows. Tools > Options > Media Sharing to set this up. For those who seek playback sharing and/or single db play history track and don't need editing it's great solution.

However I'd still like MMW use SQL Server (or at minimum a more stable solution under load/multiple users).

I agree with trixmoto that different the different SQL syntax, e.g. between MSSQL and MySQL, but also between SQLite and MySQL, is a problem. Cause of this, it schould be a database independent solution with you can also use such as NoSQL database.

But a database independent API would not be the answer of all questions. There are serveral issues which will generate a lot of support and feature requests if it's not carefully thought through. Currently, the one user frontend has the complete control over the data. There is no modification from other side in the concept. The frontend can change or overwrite data or even change the database structure on update.When you allow to change data in both directions, the data sovereignty of the frontend is lost. What you need than is to define the data sovereignty and handle the actuality of the data in MM when the sovereign is the database. This may need lock input fields or features if the database is defined as souvereign, e.g. in the case that new files are detected by an external source.

If you want to run MM in multi user mode, it goes further. Who owns which playlists? Who is allowed to change MP3 tags? There may also be performance issues.

I think external data access would be a great step forward. It would be great to have one application which can handle local media, media from NAS or even supports streaming platforms.