Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kstuart]

Since MC20 is great for both audio and video I use it for both.

I do this by using ZoneSwitch to play audio in Stereo Zone and video in Video Zone.

The still unsolved problem is that MC20 has one remote control system.

The remote control system always works only on the Active Zone.

So, more control of the Active Zone is needed.

For example, usually the last thing at night on MC20 is watching the local news recording using the Television feature.  This leaves MC20 with the Active Zone set to "Video Zone".

Every morning, I have Scheduled Tasks do:

mc20.exe /play "C:\Music\file.wav"
mc20.exe /append TREEPATH="Playlists\Smartlists\Morning"

Since those are all audio files, they play in Stereo Zone.

But the Active Zone is always still set to "Video Zone".

So, if the phone rings, and I want to pause MC20, if I pick up the remote, all it does is start last night's News video and does not do anything to Stereo Zone because it is not the Active Zone.

So, one or both of the following is needed:

* Commandline option (or command) to set Active Zone
* ZoneSwitch additional optional setting of Active Zone, in the same way that there is currently an optional stopping of other zones.

Thanks !

[mwillems]

I don't see this behavior at all; could you provide more detailed repro steps?  The active zone automatically changes with zoneswitch for me, every time.  Trying to reproduce your issue, the only way I've gotten it to "fail" is by playing things from windows explorer instead of from inside MC.  Are the files you're starting in the morning not imported (trying to think of a differentiation)?

Otherwise if I play audio, the active zone changes to audio and a stop command on the remote stops playback in the audio zone, and vice versa with video.  If I start playback from inside MC or from Gizmo or JRemote, a stop command from my IR remote always stops the currently playing zone.  

Could this be related to your locked view issue from the other thread?  Does this happen without locked views?  Alternatively, does it only happen with pause, but not stop (one of those commands requires JRiver to have "focus" the other does not, and that could be a hint).

[kstuart]

All items are already imported (I changed to that in order to see if these Zone issues would go away, and they are not affected). And actually I gave up on locked views because of that issue you mentioned, so this is without any locked views.

(For the previous year or two, I had a Playing Now locked to Stereo, so I never saw the above behavior, instead I saw the reverse behavior where it would always revert to Stereo, and so when I pressed stop on a video and pressed play again, it would start Stereo Zone because it was locked there.)

mwillems - you are not reproducing the issue I described. I'll restate:

* Reboot with media server automatically started, but not media center.
* Start playback from commandline
* Media center comes up with previous night's Active Zone still the Active Zone

I expect that this happens because when media center is not started, then the Zone Switch happens prior to any Active Zone even existing.

By the way, conceptually Zone Switch should not automatically change the Active Zone, because that is contrary to the idea of several different Zones playing simultaneously in different rooms....

[csimon]

+1

I've been asking for this too. It is impossible to play video from a remote controller, whether it's MC to MC, DLNA controller to MC, or Gizmo. I've made the same suggestion - Zone Switch needs a rule to switch to a zone if playback is started in that zone.

[mwillems]

mwillems - you are not reproducing the issue I described. I'll restate:

* Reboot with media server automatically started, but not media center.
* Start playback from commandline
* Media center comes up with previous night's Active Zone still the Active Zone

I expect that this happens because when media center is not started, then the Zone Switch happens prior to any Active Zone even existing.

Sorry, I misunderstood.  Your feature request was framed in a general way, and generally the active zone follows the zoneswitch rules for me in 90% of cases.  I can definitely reproduce what you're describing following your specific steps, and now understand that you're asking for better handling of something narrower than I thought you were.

+1

I've been asking for this too. It is impossible to play video from a remote controller, whether it's MC to MC, DLNA controller to MC, or Gizmo. I've made the same suggestion - Zone Switch needs a rule to switch to a zone if playback is started in that zone.

You may already know this, but what you're asking for already works with Gizmo if Gizmo is logged into the instance of MC you're trying to control.  It's the main way I start video and control volume on my multi-zone/zoneswitch library clients.  Especially because Gizmo shows mc instances to log into right below the available zones on the overview, it's easy to just go a little farther down and log in (instead of trying to leverage DLNA control from the server instance).  One thing i didn't figure out immediately is that when Gizmo is logged into a library client, you see the same media that's on the server, so there's no loss in functionality, but you get much finer grained zone control and more predictable playback control.

[csimon]

You may already know this, but what you're asking for already works with Gizmo if Gizmo is logged into the instance of MC you're trying to control.  It's the main way I start video and control volume on my multi-zone/zoneswitch library clients.  Especially because Gizmo shows mc instances to log into right below the available zones on the overview, it's easy to just go a little farther down and log in (instead of trying to leverage DLNA control from the server instance).  One thing i didn't figure out immediately is that when Gizmo is logged into a library client, you see the same media that's on the server, so there's no loss in functionality, but you get much finer grained zone control and more predictable playback control.

Hmm, no I don't think so? If your current active zone on the server is Zone 1 and you send something to Zone 2 via Gizmo, Gizmo won't change the active zone to Zone 2 as this would violate the conventon that you can send to multiple zones without affecting anything that's currently playing. If you have a Zone Switch rule that gets invoked then fine but the point is that you can't send video to an arbitrary zone remotely. There is no rule that can be invoked for this situation. You might have two video zones, e.g. One normal one and one with volume levelling, and you can't determine which to play in via rules that only work on the file tags.

And aplogies, I may have accidentally 'reported' your pst by hitting the report link by mistake!

[mwillems]

Hmm, no I don't think so? If your current active zone on the server is Zone 1 and you send something to Zone 2 via Gizmo, Gizmo won't change the active zone to Zone 2 as this would violate the conventon that you can send to multiple zones without affecting anything that's currently playing. If you have a Zone Switch rule that gets invoked then fine but the point is that you can't send video to an arbitrary zone remotely. There is no rule that can be invoked for this situation. You might have two video zones, e.g. One normal one and one with volume levelling, and you can't determine which to play in via rules that only work on the file tags.

I just did some testing and I get it now; it works great with zoneswitch, but not so much otherwise.

_____________________________________

So I did some digging on the core command pages, and have either of you tried using the MCC_SET_ZONE command?  I just did some testing and it changes the active zone on command, and it could be mapped to a remote control button or something. Try:

Code: [Select]

MC20.exe /MCC 10011,x Where x is the number of the zone you want counting from 0.  Having a button for each zone would be impractical, which is why passing -1 cycles through the zones in order, passing -2 cycles through zones backwards.

That seems like exactly what you want kstuart, right? It's a command to set the active zone (or seems that way based on my limited testing).

And aplogies, I may have accidentally 'reported' your pst by hitting the report link by mistake!

Ha ha, no worries  

[csimon]

That seems like exactly what you want kstuart, right? It's a command to set the active zone (or seems that way based on my limited testing).

Yeah, I guess that'll work if you're sending via the command line or using a remote control, but it's not really practical if you're using MC client, a DLNA controller or a mobile remote. If on a PC you can even invoke an RDP of your favourite flavour to change the active zone directly on the server but...it's all a bit of a faff.  Now if there was a Zone Switch rule to do it...you could set it up automotically. A rule on Zone 2 to say "switch to this zone if an item is sent to it".

I believe the Android eos remote caters for it by having two different zone selection lists - one to select the zone to play to and another to set the active zone.  JRemote (at least, the version that ran on iPad Gen 1) attempted to get round it with an option in settings to change the active zone whenever you select a zone to play to, but this only introduced another problem in that it was all or nothing and this would indeed interrupt the current zone in situations when you don't want it to.

Of course, DLNA controllers cannot do it at all, there is no DLNA protocol to change MC's active zone.  It would be best to handle it server-side with a zone switch rule rather than different methods for each individual client.

I would have thought this would be rather serious issue for the JRiver Id if it's intended to be a remote renderer as you've got no way of sendiong video to it if you've got multiple zones.

[mwillems]

Yeah, I guess that'll work if you're sending via the command line or using a remote control, but it's not really practical if you're using MC client, a DLNA controller or a mobile remote. If on a PC you can even invoke an RDP of your favourite flavour to change the active zone directly on the server but...it's all a bit of a faff.  Now if there was a Zone Switch rule to do it...you could set it up automotically. A rule on Zone 2 to say "switch to this zone if an item is sent to it".

Yeah it's definitely not a perfect solution, but for kstuart's use case where he's already running automation commands and just wants to set the active zone alongside the play command, it seems like a slam dunk.  

I would have thought this would be rather serious issue for the JRiver Id if it's intended to be a remote renderer as you've got no way of sendiong video to it if you've got multiple zones.

I think video support is new enough on the Id that it hasn't come up yet.  I agree that it is an odd corner of MC.

[JimH]

There are a few odd corners.

[mwillems]

There are a few odd corners.

You can't have a multi-faceted product without producing a few odd corners   

[kstuart]

I tested MCC 10011 in "Run" and it seems to work fine, so I added it to my morning batch file and will report back tomorrow.

Thanks for finding that (I did check the wiki and did not see it).

[mwillems]

I tested MCC 10011 in "Run" and it seems to work fine, so I added it to my morning batch file and will report back tomorrow.

Thanks for finding that (I did check the wiki and did not see it).

It was in a weird spot, it took me a few looks to find it (I only found it because I had a vague memory that it existed, because I was fiddling with it pre-zoneswitch)

[kstuart]

It did not work:

mc20.exe /play "C:\Music\file.wav"
mc20.exe /append TREEPATH="Playlists\Smartlists\Morning"
MC20.exe /MCC 10011,0

where media server is running, but media center is not running, "2" is the zone last run (the night before, prior to automatic early morning reboot), and "0" is the Stereo (audio) zone.

This is probably related to the other issue where Zone Switch does not change the Active Zone if media center is not running (using Windows Explorer->Media Center->Play on a previously imported file, when MC is not yet running).

In that issue, ZoneSwitch will correctly choose the right Zone, but Media Center still comes up in the previously used Zone.

So, if you start a Video, but Media Center was previously used to play Audio, then you will only hear the sound, and pressing remote buttons does not pause or stop your Video so that you can switch Active Zone.

[mwillems]

Well that's a bummer.  You could still map the "-1" version of it to a remote key to cycle through the zones, but that's much less convenient.  Sorry it didn't work.

[kstuart]

Even that would not work, because the TV is off at that point, so I don't know what the Active Zone is.

The problem seems to be that the ZoneSwitch code does not do anything with regards to Active Zone.

And the situation with Locked Views of Playing Now, shows that Active Zone code is separate and related to entirely other things.

So, the ZoneSwitch code needs to have a line of code at the end:

  Set ActiveZone to [ Zone selected by ZoneSwitch ]

Since most of the time, this happens anyway, the explicit line of code would take care of the cases where it does not happen.

[mwillems]

The problem seems to be that the ZoneSwitch code does not do anything with regards to Active Zone.

Just to clarify, that's not true in general, it's only true in cases where playback is started from outside MC.  When MC is in theater view, for example, and I start a video remotely with Gizmo, MC switches zones and also changes the active zone to match.  Same behavior when starting playback via IR remote, or with a mouse and keyboard in MC.  In my testing, Zoneswitch only seems to not change the active zone when playback is initiated from outside the program (either from explorer or the command prompt).  If you have disconfirming examples, let me know.

So, the ZoneSwitch code needs to have a line of code at the end:

  Set ActiveZone to [ Zone selected by ZoneSwitch ]

As long as that addition didn't apply to WDM playback, I'd be happy with that.  If it applied universally, it would wreck the WDM driver's utility.

[kstuart]

As long as that addition didn't apply to WDM playback, I'd be happy with that.  If it applied universally, it would wreck the WDM driver's utility.

I'm confused.

The previous paragraph you stated that ZoneSwitch always changes the Active Zone (with the one exception under discussion in the thread).

Then in the second paragraph, you state that having ZoneSwitch always changing the Active Zone would wreck something.

[mwillems]

I'm confused.

The previous paragraph you stated that ZoneSwitch always changes the Active Zone (with the one exception under discussion in the thread).

Then in the second paragraph, you state that having ZoneSwitch always changing the Active Zone would wreck something.

I wasn't clear (I was writing quickly), and I apologize for the confusion. My experience is that zoneswitch generally changes the active zone; playback started from outside JRiver (whether from the command line or explorer) is one exception to that rule; WDM input is another longstanding exception, although it may just be another flavor of the same exception, as the WDM audio stream is often started from outside of JRiver.  

I had always assumed, though, that the WDM behavior was "by design," as the fact that it doesn't change the active zone is the only reason it works correctly with JRiver's internal browser.  If you have the WDM driver set up, and have it set to route to it's own zone, zoneswitch won't change the active zone based on WDM input, which is good or it would effectively stop playback and navigate away from whatever youtube video you were trying to watch in the other zone (Which is what happens when you try to use the WDM driver without zoneswitch).  

The WDM is a special case though, obviously.

[kstuart]

Mysteriously, there seems to be some difference in the problem with whether or not a reboot is done.

In other words, if MediaCenter has been used earlier, and then closed, and media server is still running, then sometimes the problem does not occur (ie Zone Switch will change the Active Zone even with MC not initially running).

But, if a reboot is done, then the problem always occurs.

It would seem that the first use of MC after a reboot, starts something that makes ZoneSwitch able to change the Active Zone even when MC is subsequently closed.