INTERACT FORUM
More => Old Versions => JRiver Media Center 23 for Windows => Topic started by: Gianni on June 09, 2017, 08:26:49 am
-
Is it possible to implement the following features?
- The close button reduces MC to tray icon
- Auto start MC at Windows startup reduced at system tray
Thanks
-
Under Tools > Options > Startup, you can find the possibilities.
-
I'm sorry but i'm not able to find exactly what I described in my request.
I found only "minimize to system tray" but I would like to "close to system tray", also "Run on windows startup: Media Center" but i would like that MC starts reduced to tray icon
Thanks
-
Set MC to start the Media Server at Windows startup, that should give you a behavior like this.
-
I'm sorry but i'm not able to find exactly what I described in my request.
I found only "minimize to system tray" but I would like to "close to system tray", also "Run on windows startup: Media Center" but i would like that MC starts reduced to tray icon
Thanks
as far as start MC minimized...the standard windows feature should do that with or without "start the media server at windows startup.....I don't see any option to "close to system tray" if you have it pinned there is no need for it!
-
+1
When Media Server is running, JRiver should close to tray and not stop audio playback when you do it.
-
+1
When Media Server is running, JRiver should close to tray and not stop audio playback when you do it.
This beavior is usefull also for JRiver WDM driver. If I close MC, WDM driver stops to work.
For a flawless use of WDM driver, MC has to auto start minimized to tray and the close button has to minimize MC to tray.
-
jriver won't change this behaviour: https://yabb.jriver.com/interact/index.php/topic,106312.msg742315.html#msg742315
-
This beavior is usefull also for JRiver WDM driver. If I close MC, WDM driver stops to work.
For a flawless use of WDM driver, MC has to auto start minimized to tray and the close button has to minimize MC to tray.
Indeed.
It would also be preferable to have a mode which keeps the WDM driver always-active too, since it often gets stuck in an "Opening..." state that never recovers without manual intervention. (fixing that bug would also be nice)
jriver won't change this behaviour: https://yabb.jriver.com/interact/index.php/topic,106312.msg742315.html#msg742315
I have hope that they will come around to the idea that it should be difficult to "kill" playback when you're using JRiver as a media server, and not just a media player.
It should close to tray, and that should not stop media playback.
The only way to kill playback should be to have it in the context menu of the tray icon, and it should ask for confirmation before exiting.
-
I have generally got used to this but my family would agree the current behaviour is surprising. Close to tray seems pretty common behaviour in a player app to me btw
-
The MC application should ideally be split into two separate applications..
1) MC Player should become a Windows Service Application. This exposes no UI at all, and runs when Windows starts. It always runs in th background regardless of whether a user is logged on, and regardless of whether th UI application (see below) is running.
2) MC Browser should be (should remain) a Windows Application. This exposes the whole UI, including track browser, play commands, playing now, tagging, audio analysis, file rename, copy, move etc. It only runs when a user starts it. And stops when the user stops it.
The Browser application talks to the Player application by means of standard Windows interprocess calls. In the case of MC, probably either by the COM interface, of MCWS.
I know that this architecture can work, since this exactly how Logitech Media Server (Squeeze Box player) works. And my own Whitebear Media Server UPNP shim for LMS works also in the same way.
This is quite liberating as a design architecture, since it represents a real and proper split into the client/server architecture.
PS if MC were ever to shift to a 64 bit build, this would be the perfect opportunity to split the application into client (regular application) and server Windows Service Application) parts..
And indeed when MC is operating as a networked client/server application across several PCs it is in fact functioning virtually as described above. It is only in the case when MC is operating on a single PC that it does not clearly separate the client/server parts.
-
We're not going to change the entire architecture of Media Center. And being 32-bit or 64-bit is absolutely unrelated to that entire topic either way.
-
I think we would rather write an OS before restructuring MC.
-
While it would be nice if JRiver had unlimited resources to do something like that, I think it's a big leap from what some of us are asking for.
Activating "Media Server" really is just the same thing as "close to tray" already - it just adds a second icon for it. (I'm not sure why)
The main issue with it right now is that it stops playback in all zones right now when you do that.
I don't think it would require any major changes to the Media Server behavior to satisfy those of use who want to use JRiver as more of a "server".
1. Closing to tray no longer issues stop commands. Playback continues in all zones without interruption.
2. The "Close Media Server" option asks for confirmation.
3. The context menu for Media Server is updated with a few commands:- Stop playback in all zones.
- Zones are listed on the main context menu rather than a sub-menu
- Play/Pause/Stop/Next/Prev controls as a sub-menu for individual zones (similar to the "Controls" menu for Zones in Media Cetner)
- If it is possible, add icons to indicate playback status for a zone in the Media Server context menu. (active/paused/stopped)
-
I think we would rather write an OS before restructuring MC.
Yeh. I know.