Yes they will as soon as they need to create a playlist or manage their library.

Perhaps you are looking at the design in very technical terms and not primarily at the general user operational need for persistent DLNA server functions and separate management functions. I do not get your logic most of the time on this point and I strongly disagree with your view of simple wins at the cost of inflexibility and interruption of DLNA server functions (yes -- in your "service").

Lowlander, I run a setup like this and I DO have the problem I am describing. The problem has nothing to do with NAS or other devices.

When you have this setup, media streaming from the service IS interrupted when you run MM. Media streaming IS interrupted again when you close MM. This is not acceptable.

How can I say this more simply for you?

We are aware of that, MediaMonkey is designed decade ago, then there was no NAS and iPhone, Android and .... (at least now as available and cheap as now) where things were much simpler. We evolve with future and there are big plans (I seen them and they are gorges) for MMW in order address such problem.

Anyone here can say that each mayor build bring things further without loss to our users. Just patience, few years ago almost no one in team had Linux based NAS and one we had was on ARM and slow CPU/RAM costing triple than Intel based dual core NAS with Multimedia Station and HDCP output, there was no Smart TVs (and its APIs).

Think that Dev team is not also obtaining and absorbing new technology we can develop new things, which we already do.

If someone remember in 2001/2 Winamp is used as player, than users asked for internal player, than skinning, more features, scripting, Synching, .....

I have the service installed and I have the problems described above. These problems are directly related to the "headerless" service being installed and running and THEN logging in and running MM. I hope you will understand this important issue.

In my view, the function of the service is to behave as a DLNA server that is always operating when your computer is running and even when you are not logged in.

The problem is that the service is being impacted by running the MM application -- media streaming being provided by the service is interrupted when you run MM. If you start the stream again and then log off MM, then the media stream is interrupted again and you need to restart it. I assume this has to do with the DLNA server function switching between the service and the MM application when you start and shutdown the MM application. This is the part that is broken and needs to be fixed.

The reason for the service (not server!) was to allow headerless installs (no screen/input devices), as a service can run at PC start (without logging in) and software can only run after logging in (problematic in a headerless setup). Those who run a setup like this will likely never have problems with interruption (of the DLNA server run as part of the service).

So here is the reason why the suggestions I have made in this thread need to become part of the design in a new release. MM needs to have two application components: a server and a management client. A user should be able to control when and how the server runs with the following options:

1. Server only runs when management client is started (default) -- this means you really don't have a DLNA server unless you run the app. Even then the server should ONLY RUN if you select this option because there is still an option 3.
2. Server is always running -- this means the state of the server NEVER CHANGEs when you run the management client. The server only stops when you explicitly stop it and it is not impacted by running the management client.
3. Server is never running -- this allows a different computer to operate as the server IF YOU WANT TO RUN THE MANAGEMENT CLIENT while the server is running somewhere else.

The rationale for this is SIMPLE and would make a SIMPLER application:

Right now, the status of the server **CHANGES** when you do not want it to. If you configure the server to be running, and then you login and run MM, the status of the server changes: any music stream that is playing discontinues and you have to start your music player over. The SERVER FUNCTIONS ARE INTERRUPTED by running the management client. This is extremely BAD FORM in the client/server application space where servers are expected to run continuously until they are explicitly stopped. This is a design fault and has to be fixed no matter what. My wife became confused when I told her she only needed to use her Onkyo app to access and run music now (I had completed all the MM setup for her). She logged in to create a playlist and then told me that her music would not play. She left my login active and she said she finally got it to work. I came home and stopped the MM management client and her music stopped again. This is a ridiculous design that only considers that MM is a personal application (OR the client and server are is seriously constrained by no concurrent media database use). If MM offers a DLNA server function, then it should be designed as a server functions that is NOT IMPACTED IN ANY WAY by the running of the management client. The options I listed above allow everyone to have it their way.

Please fix this design fault and STOP calling the current design SIMPLE.

PS: I started to look for another DLNA server to use so that I would not have this problem. The way I thought I could fix it would be to move my media library onto my Synology NAS and start the DLNA media server on the NAS and then use MM to manage the library. In this case, I would want option 3 above for MM!!! The problem was playlist management was not consistent across the NAS Media server and MM so I went back to using the MM server. Arghh ... I DO NOT HAVE CONTINUOUS OPERATION OF THE SERVER WITH MY CURRENT MM INSTALLATION.

Peke ... that is why the tidbits about 5 sound so interesting ...

Thanks for the reply

I Think that you are talking about same thing thru different eyes.

I would love to see MMW as two separate apps eg. One Service/Server app without GUI and one client app that will tell Service/Server what to do.

But MMW is designed now that it is not possible to do exactly that, but who knows what will future bring us.

Lowlander wrote:What's the point of MM accessing the service, you gain nothing and make things more complicated. Add to it that you can't tag over DLNA which is the main feature of the service.

If you are responding to me the I would have to say HUH?

However they still need to operate on the same database. I still see this as making things more complicated instead of solving a problem.

I agree that the MMW Application needs to be a player and needs to be able to manage the media database, create collections, playlists, and adjust options for the server, etc. The MM Application does NOT need to include the DLNA server really.

It could be that the MM Service operation is controlled as follows:

If the user has elected NOT to have the MM Service running all the time, then it is started as a process in the MM client application process space (a subprocess or however this might be done properly without installing a MM Service). Functionally, it would behave like the MM Service but it would start and stop under direct control of the MMW Application.

If the user elected to have the MM Service available, THEN when you run the MM Application it DOES NOT need to start the MM Server process in its process space but instead leaves the task of serving to the MM Service.

In this case, the DLNA server could be one separate piece of code that runs in two different contexts depending on the user's election but is NOT duplicated. Duplication seems to be one of the issues Lowlander is trying to avoid.

I think this is the best approach. We need to NOT think about MM as just a client application when the DLNA standards define several components that can operate together. Separating the DLNA Server from the client application makes very good sense architecturally.

What's the point of MM accessing the service, you gain nothing and make things more complicated. Add to it that you can't tag over DLNA which is the main feature of the service.

I would prefer that MM be enhanced so that the "service" is just that. And that MMW is simply a Client (UI) of that service. I think in the sense of design that is a much better way to go. There is no need to have both the service and MMW running at the same time that I can see.

I would be very interested to see other user opinions on what I have suggested here.

What the service serves up is defined in Tools > Options > Media Sharing in the Media Server settings. You can select any Collections/Playlists to be shared. What is shown in MMW is set under Tools > Options > Media Tree.

If there are bugs in the implementation it doesn't mean the implementation is theoretically wrong. I have not testing switching while DLNA serving is happening, but frequently on restarts of MMW (no service running) DLNA playback on clients was uninterrupted.

I'm also you can do what you want running to separate installs of MediaMonkey (one running as service, one as regular).