What roles will MMS have?

[Linwood]

This is probably documented somewhere, and apologies for not finding it if so, but I wonder if I can go up to the top level and just ask: In your vision, for the longer run, what role will MMS vs MM5 have?

I assume it will be a proprietary server for MM5 to use to obtain content from MMS's database. Proprietary in that it is not an existing protocol, but you said it's open code so I assume open interface for other people to build clients if desired.

But will MMS also be a renderer? Let's say that MMS is installed on a box that has speakers attached. Can MMS itself server as a DLNA renderer so that other devices with music can play on it (say a guest with a phone that has content, stuff not in MMS's database)?

Along the same lines, can MMS be a player for local hardware from its own database, say you install it on a headless linux box with speakers, can MM5 (on a different machine, or phone) tell MMS to play through those speakers directly?

These answers may be around here somewhere, but if all this is published with an open API, apologies for asking stuff already documented, and any pointers... ?

Maybe I should just download and try, but I'm trying to understand whether it actually solves any problems I have. Plus it doesn't look like it's very actively being developed/used yet, so too early?

Linwood

[Lowlander]

MMS is just the server, it will serve to MediaMonkey products like MM5 and MMA (future). You'll need MM5 for any playback capability.

[jiri]

MMS is 'just' a server, but its UI part can be opened in any browser and it can work as a renderer then. If you do both on the same machine, you can actually have both server+renderer.

It wasn't too actively developed lately, mostly because we focus on finishing MM5, but we count on it in the future. Feel free to test it, any feedback will be welcomed!

Jiri

[Linwood]

MMS is 'just' a server, but its UI part can be opened in any browser and it can work as a renderer then. If you do both on the same machine, you can actually have both server+renderer.

So a question and a suggestion.

Maybe I have the terminology wrong, but to me a renderer (at least a DLNA renderer) is one that offers to play music served from a remote server on local hardware. So for MMS to be a renderer, it would mean someone can walk in with a cell phone, and see MMS as a dlna speaker available, and play music from the cell phone on MMS's attached speaker. MMS would never have the song in its database, it's just doing a pass thru. I actually doubt it would include this, but curious.

To be a player, from the UI you could ask MMS to play onto a local (or remote DLNA or cast) speakers. I am assuming it can do this, i.e. I connect to the UI, and play to locally attached speakers (if any) or to a chromecast enabled speaker from the MMS box. No separate instance of MM5 required to be running, just MMS access by a browser.

Or... maybe I am using the wrong terms? But do I have the right sense of what it will do?

The suggestion is in addition to the UI, consider a documented RESTful interface so other programs can remote control MMS not just using the UI but with web posts directly. That may all be there under the covers of the UI of course, but if you provide the hooks to avoid the UI and post requests directly, home automation systems can then integrate with it, and you can label it "Works with Home Assistant" or "Works with Homekit" or even (cloud required probably) "Works with Alexa".

[Lowlander]

MMS is only a Server (MediaMonkey Server), rendering capability comes from MM5 and both can be installed on the same machine. It's designed to host the database and DLNA serve media files. Any managing of the database is done through MM5 and rendering of DLNA playback is done by DLNA capable clients.

MMS is designed to take the database/DLNA out of MM5 if a users so require for their setup.

[jiri]

To clarify, there's:

• MMS - a server

• MMS UI - web user interface that's accessible from any browser and served by MMS

Here, MMS UI in a browser can act as a renderer in the sense that it can be controlled e.g. from another MMS UI instance, or (in the future) e.g. from MMA. That said, MMS UI is not a DLNA renderer, since it isn't possible to implement it in a browser. I guess that this could be solved MMS acting as a proxy, should there be enough interest in such a feature.

Anyway, as Lowlander wrote, any DLNA renderer will work with MMS.

As for the RESTful interface - it is there (in MMS), just not documented yet, mainly because this is a work in progress. Since it's open sourced though, you can look up details even before there's a documentation finished.

Jiri

[Linwood]

As for the RESTful interface - it is there (in MMS), just not documented yet, mainly because this is a work in progress. Since it's open sourced though, you can look up details even before there's a documentation finished.

Good to know. I should have a lot more time after the first of the year, I may well dig into that.

My ideal system would be MMS running on my home automation server in a closet, MM5 available as a client on the piano's display if someone wants to manually select songs, but MMS being able to be remotely controlled from my home automation system by voice, playing through either that MM5 client or some dedicated DLNA renderer (e.g. gmrender-resurrect works fine).

I think that's better than remote control of MM5 since it doesn't require the GUI even be displayed.

This also of course gives voice control of audio playback to any of the myriad of cast/dlna speakers I have spread around, but I already have that with GPM. However, who knows what the Youtube migration will bring, so getting MMS controllable by voice may be a needed migration path if Google screws up GPM.

Thanks for the discussion.

[Quirken]

MMS is 'just' a server, but its UI part can be opened in any browser and it can work as a renderer then. If you do both on the same machine, you can actually have both server+renderer.

It wasn't too actively developed lately, mostly because we focus on finishing MM5, but we count on it in the future. Feel free to test it, any feedback will be welcomed!

Jiri

Why hasn't there been a server alpha release since 0.2.2 in Feb 2019?

Looks like the github project is up to version 0.3.1... is there any reason I should stick with 0.2.2?

[Peke]

Hi,
Only Pre-compiled binaries are on 0.2.2 Git is updated as you noticed.

If you can use Git and compile yourself you should update, too much work on MM5 past year. Especially as MMS is working with/from MM5 I expect to be more worked on after MM5 gets out.

[Quirken]

Yeah, unfortunately 0.3.1 is still quite bare bones, though there are some improvements over the "released" version.

Any chance the web UI might get "shuffle all" and "next track" buttons in the next few months? Having to manually queue every song makes it more proof-of-concept at this point.

(I'm excited about MM5/the server, since I'm using Linux these days, but I suspect that's years away from release.)