MM Service and App Services

Beta Testing for Windows Products and plugins

Moderator: Gurus

ILC
Posts: 16
Joined: Wed Oct 03, 2012 1:37 am

MM Service and App Services

Post by ILC »

I am not sure why you think it is a good idea to have the MM application stop the MM Service and have it start again when the MM application stops. This sound complicated. If the MM Database is shareable between the two processes, then can you not consider this approach to design:

1. MM Service installation is a prerequisite to allowing any collection to be served by the MM Service. The MM Service once installed is operating all the time even when the MM Application is operating. The MM Service can be manually uninstalled at any time as well. The Media Sharing screen has the "Install MM Service" and "Uninstall MM Service" options on it.

2. Any collection managed in Options/Library/Media Sharing has the option of being served up by the MM Service (if installed) or the MM Application (if running). No collection can ever switch between the MM Service and MM Application simply because you ran the application. At any time, a collection can be served up by one and only one of the processes based on a new user election in the Media Sharing screen. The user election to select the MM Service to share a collection is NOT available unless the MM Service is operating.

As a user, I should NOT have it complicated the way the current Beta is. I should be forced to make a choice on what process is doing the DLNA serving for a collection and stick with it. I can change it at any time but I cannot have it switch between MM Service and MM Application -- it is too complicated.

In this case, any collections being served by the MM Service would appear as Media Servers in the Media Tree but they would never be duplicates of collections being served by the MM Application when you run it. It would be very interesting to have the MM Application operate this way and also provide an option for a separate system or even a network storage server (Synology, for example) to be the MM Service for collections. In this case, the MM Application may have to trust the user that you have a MM Service running somewhere else that will do the work.

The Add Shares window could have the following mutually exclusive options for each collection to be served by:

1. Served by MM Application
2. Served by Local MM Service (MM Service must be installed and operating to select this option)
3. Remote MM Service: MUMBO (perhaps server is named in case you may have several MM Servers running on the same network sharing the same database and configuration files).

If the database or a separate control file specifies which process is entitled to DLNA serve a collection and this control file is managed by the MM Application then the MM Application and the MM Service don't really need to interact much other than through the configuration file.

This may also allow the two processes to access the meta data for media files from separate systems (Windows and Linux, perhaps) as in my example above without any coordination of access. The MM Service should only need to read the meta data. The MM Application would have the maintenance and management access for metadata. In my scenario, one common storage location should be used for the MM database and configuration files so that all processes can access it. In turn, the network storage server could host the media files, MM.DB and configuration files and allow them to be managed by the MM Application through a file share.
Lowlander
Posts: 56491
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: MM Service and App Services

Post by Lowlander »

Because they're duplicates of each other. There is no need to run the service when MMW is running as MMW has everything and more than the service has to offer. Lots of users are not going to want the service running so making it required would be a bad move.

Its done automatically in the background, all you do is enabled the service if you want to use it (main use is headless servers), how is that complicated?
ILC
Posts: 16
Joined: Wed Oct 03, 2012 1:37 am

Re: MM Service and App Services

Post by ILC »

I never suggested that you make it required. I suggested that you have an "Install MM Service" and an "Uninstall MM Service" option and give complete control to the user.

What I DID suggest is that for any collection being served, for the reasons you state in your reply, you should be able to provide the option for a user to have the collection be served by the MM Application OR the MM Service as a mutually exclusive option. When the MM Service is NOT installed, then this option is greyed out and not available. Installing the MM Service would enable the option to select which process will serve up a collection and the user would be allowed to select either but not both of the MM Application or MM Service for each collection.

This should allow you to stop the MM Service shutdown and startup controls (which I referred to as complicated) when the MM Application is used because the user options are specified in a way that makes the role of the two server process NOT collide -- they will never try to serve the same collection at the same time.

Now, obviously the automatic shutdown and startup of the MM Service is complicated because it does not work yet as per my error messages with the latest release:

The description for Event ID 0 from source MediaMonkeyService.exe cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event: The service process could not connect to the service controller

AND, I can imagine the communication between the processes to be fairly complicated. What I am suggesting is that it does not have to be. Using a MM Service is optional, and if used, a user must choose only one process to serve a collection and the process responsibility to serve the collection DOES NOT CHANGE when the MM Application is run.

A VERY CLEAR advantage of this is for people who want to use a MM Service but then want to use MM Application on demand to browse, add media, or create a playlist **WHILE music is being listened to**. The way you have designed this will cause interruption to media serving by MM Service when you run the MM Application !!!!!

We are using MM Service and dancing to music at a party while someone arrives with a USB stick and says why don't you load this and play it. I go to my party of dancing friends and say, hold on while I run MM Application to load this USB stick because the music will stop when I run the MM Application. Everyone in the room groans at me, grabs their drink and says, "why aren't you using iTunes".

Understand?
ILC
Posts: 16
Joined: Wed Oct 03, 2012 1:37 am

Re: MM Service and App Services

Post by ILC »

PS: I don't care if the MM Service and MM Application are duplicates of each other as long as I have control over which process will serve each of collections. The ones I want on-line all the time will be served by MM Service. The ones I am building and testing would be served by MM Application (only when I run the app of course).
Lowlander
Posts: 56491
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: MM Service and App Services

Post by Lowlander »

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).
ILC
Posts: 16
Joined: Wed Oct 03, 2012 1:37 am

Re: MM Service and App Services

Post by ILC »

I would be very interested to see other user opinions on what I have suggested here.
dtsig
Posts: 3588
Joined: Mon Jan 24, 2011 6:34 pm

Re: MM Service and App Services

Post by dtsig »

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.
Where's the db and ini stored
Reporting Bugs
Where tags are stored

Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Lowlander
Posts: 56491
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: MM Service and App Services

Post by Lowlander »

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.
ILC
Posts: 16
Joined: Wed Oct 03, 2012 1:37 am

Re: MM Service and App Services

Post by ILC »

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.
Lowlander
Posts: 56491
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: MM Service and App Services

Post by Lowlander »

However they still need to operate on the same database. I still see this as making things more complicated instead of solving a problem.
dtsig
Posts: 3588
Joined: Mon Jan 24, 2011 6:34 pm

Re: MM Service and App Services

Post by dtsig »

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?
Where's the db and ini stored
Reporting Bugs
Where tags are stored

Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Peke
Posts: 17457
Joined: Tue Jun 10, 2003 7:21 pm
Location: Earth
Contact:

Re: MM Service and App Services

Post by Peke »

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.
Best regards,
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
Image
Image
Image
How to attach PICTURE/SCREENSHOTS to forum posts
dtsig
Posts: 3588
Joined: Mon Jan 24, 2011 6:34 pm

Re: MM Service and App Services

Post by dtsig »

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

Thanks for the reply
Where's the db and ini stored
Reporting Bugs
Where tags are stored

Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
ILC
Posts: 16
Joined: Wed Oct 03, 2012 1:37 am

Re: MM Service and App Services

Post by ILC »

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.
Lowlander
Posts: 56491
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: MM Service and App Services

Post by Lowlander »

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).
Post Reply