Print

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

[masterjoe]

Well, as MCWS is the default developer's API now I have written a wrapper for Python to control MC fully via MCWS.
Everything works fine so far... HOWEVER zone specific MCC commands are not really targeted to the zone I specify!
They always end up in the previous active / first zone.

So being in theater view with a movie highlighted I might send a command like this:

http://127.0.0.1:52199/MCWS/v1/Control/MCC?Command=27000&Parameter=13&Block=0&Zone=10029&ZoneType=ID

which shall begin playing the movie in the given zone... BUT MC unexpectedly uses the first zone (last active?) to perform the command instead of the correct one that has been specified with the MCC command as can be seen above!?

This looks like a bug to me. Whenever specifying the zone MC MUST invoke the command for the specified zone and no other zone!

Or is there something I am missing?

[Matt]

I can't reproduce this.

I make this simple command:
http://localhost:52199/MCWS/v1/Control/MCC?Command=10000&Zone=10093

That's a play / pause command.  And picking a different zone and issuing that command sets zone 10093 playing or pausing.  No drama.

Thoughts?

[masterjoe]

Well non-MCC commands do all work! But the reason I am posting this is that from my experience at least some MCC commands do not.

As I map the "enter" key generically to MC (controlling MC with a IR remote) I cannot directly invoke the "playpause" because I do not actually know whether I really CAN playpause (that contextually depends on where you are in theater view!) and this is the reason why I am forced to trigger a generic "enter" key instead of any specific play command.

Here on my machine with several zones it picks the incorrect one and the movie plays elsewhere - bad.

Pls try the following:
1) play something in the first zone (index 0) and then pause this playback
2) now invoke the MCC command "enter" (as seen in my initial post) for a DIFFERENT zone with a playlist in it (you should potentially navigate to this list via theater view so that the item to be played becomes highlighted before actually invoking the "enter" key!)

Does this work for you?
Here on my machine it continues playing zone (1) instead of starting playback for zone (2)...

[masterjoe]

Maybe I should be more detailed on what exactly is the problem here. In fact I have a multi-soundcard scenario. One of the "soundcards" is HDMI audio for the TV. Other soundcards are local speaker sets in different rooms conntected via USB.

I have several "music" zones and one for my TV set which all use different soundcards.

Starting theater view displays MC correctly and using the cursor keys and "enter" via MCC I navigate until I finally found a movie that I like for playback. When I play back the movie by invoking yet another "enter" through MCC it might play on one of the "music" soundcards - which is in a different room! So the audio comes out at the wrong place while I can see the movie playing!

This is because MC does not respect the zone for (some?) MCC commands issued via MCWS where it should respect it. I have checked on which zone the movie actually plays when the audio comes out of the wrong soundcard and found that MC indeed uses the wrong zone although the command explicitly specifies the correct one.

[millst]

Zones don't apply to all MCC commands. I would guess that targeting a zone doesn't apply to a keypress (27000). After all, you're just sending button presses to the UI.

Once you have started playback in a zone, that is the current zone for MC. It doesn't matter what your view is (playback or regular). To playback in a different zone, you would need to select a different zone through the UI or make use of ZoneSwitch.

If you want do automate everything through MCC, you could issue two commands. One to set the zone (MCC_SET_ZONE/10011) and then send your keypress. There is probably a more direct MCWS command to switch zones, too.

-tm

[masterjoe]

Zones don't apply to all MCC commands. I would guess that targeting a zone doesn't apply to a keypress (27000). After all, you're just sending button presses to the UI.

Once you have started playback in a zone, that is the current zone for MC. It doesn't matter what your view is (playback or regular). To playback in a different zone, you would need to select a different zone through the UI or make use of ZoneSwitch.

If you want do automate everything through MCC, you could issue two commands. One to set the zone (MCC_SET_ZONE/10011) and then send your keypress. There is probably a more direct MCWS command to switch zones, too.

-tm

Thanks for your post. Well, as you say you are guessing - because it is NOT documented which MCC commands are actually using zone parameters and which are not. MCWS allows to specify the zone for ANY MCC command.
Maybe it can be seen as a missing feature that some MCC commands do not work zone specific where they really could / should. What really happens in theater view when the enter key is invoked for a highlighted file is that it becomes played. And in exactly this case the zone parameters should be passed through to the resulting play command! Then there would be no problems at all in my scenario!


Regarding your suggestion... What happens when multiple users are using MC at the exact same time? I really intend to use MC for two people or even more where one might be watching a movie and the other is listening to music. Setting the zone explicitly before actually performing any other command does theoretically work but might produce single-source collisions when this is happening simultaneously. Both users create truely concurring events. I was hoping to be able to solve this by using explicit zone targeted commands.


So I still tend to think that MC is not doing it right here! Zone parameters should be used whereever it makes sense! And my case is one of those...

[eddyshere]

Well non-MCC commands do all work! But the reason I am posting this is that from my experience at least some MCC commands do not.

Agree
https://yabb.jriver.com/interact/index.php?topic=105477.0

Funnily in my case MCC direct input always works but invoking MCC commands through MCWS doesnt

[blgentry]

As I map the "enter" key generically to MC (controlling MC with a IR remote) I cannot directly invoke the "playpause" because I do not actually know whether I really CAN playpause (that contextually depends on where you are in theater view!) and this is the reason why I am forced to trigger a generic "enter" key instead of any specific play command.

That doesn't make sense at all.  MCWS commands don't care about context of a particular view.  If Play/Pause can work, it works.  If there's something queued up, or paused, or playing, or stopped, Play/Pause will work.

The idea of sending key presses to an interface with specific commands defined already just seems like asking for trouble.  Why in the world would you not use the commands that you want to execute instead?  What happens when you try specific MCWS commands instead of key presses?

Brian.

[masterjoe]

That doesn't make sense at all.  MCWS commands don't care about context of a particular view.  If Play/Pause can work, it works.  If there's something queued up, or paused, or playing, or stopped, Play/Pause will work.

The idea of sending key presses to an interface with specific commands defined already just seems like asking for trouble.  Why in the world would you not use the commands that you want to execute instead?  What happens when you try specific MCWS commands instead of key presses?

Brian.

I do not agree with your point of view. The point is: I do use very simple IR remotes with MC wich only have a few keys, mainly Menu, Up, Down, Left, Right, Enter, Back. And MC is pretty usable using only these keys - besides the zone problem. Additionally it is much much easier to navigate this way as other keys as play / pause etc. are not really required.

So I do not use specific commands (for the remotes!) for at least these reasons:

a) they are not really required because navigating with fewer keys is much more ergonomic and much faster
b) my remotes to not have any further keys to be mapped as play / pause etc.
c) I do not know when to switch from plain "enter" to "playpause" etc. because that depends on the context (the exact position in theater view)

So I won't change my mind that it's a missing functionality that commands that CAN be zone specific are not. It's really almost just the IMPLICIT play that MC does wrong. And why should I even consider changing a ton of things when this simple thing DOES make sense and is also not hard to do?? Any command could have a zone context and whether it is evaluated depends on the RESULTING command itself. So yes, when an "enter" key is received which causes an IMPLICIT *PLAY* command to be fired within the engine then this command must regard the provided zone and must be zone dependent WHEN a zone has been provided with the command. Only if NO zone has been provided it shall use the current zone.

I can not even see a reason why you oppose such a logical behavior??

[masterjoe]

Agree
https://yabb.jriver.com/interact/index.php?topic=105477.0

Funnily in my case MCC direct input always works but invoking MCC commands through MCWS doesnt

Well, because I ONLY use MCWS now (as it has been stated that this is THE way to automate MC) I have not tested the "MC21.exe-way" to do it. Maybe I will test this - but it is pretty ugly to use two different ways when there should be a solution for MCWS already available.

So what you say pretty much indicates that the issue of my thread is a bug.

[blgentry]

I do not agree with your point of view. The point is: I do use very simple IR remotes with MC wich only have a few keys, mainly Menu, Up, Down, Left, Right, Enter, Back.

Wait, wait, wait.  You are somehow mapping IR remote keys to MCWS commands that are submitted via TCP/IP ?  Why aren't you using an IR receiver and letting MC handle the reception and translation of IR commands?  That's how it's intended to be used.

Brian.

[masterjoe]

Wait, wait, wait.  You are somehow mapping IR remote keys to MCWS commands that are submitted via TCP/IP ?

Yes I do.

Why aren't you using an IR receiver and letting MC handle the reception and translation of IR commands?

Because I do MUCH more than just control MC with my remotes. I have a customly programmed Python-based home automation system where MC is only one part of many. I do not want to let MC dictate how I am doing things. I want my automation system to do that. It is very strongly context driven.

Therefore the generic approach using MCWS as middleware is the only way because my remote might send totally different NON-MC commands on the EXACT same keys of the remote! My system knows in which mode I am and directs the commands accordingly! My system is strictly context-aware! The mapping of any key of my IR is totally context-dependent.

So MC is the slave here, not the master

[Matt]

Zones don't apply to all MCC commands. I would guess that targeting a zone doesn't apply to a keypress (27000). After all, you're just sending button presses to the UI.

This is correct.

I don't even know what a zone would mean attached to a MCC_KEYSTROKE (27000) command.

Right now it just simulates the keyboard pressing the button.  There's nothing about it to be zone specific.

[masterjoe]

This is correct.

I don't even know what a zone would mean attached to a MCC_KEYSTROKE (27000) command.

Right now it just simulates the keyboard pressing the button.  There's nothing about it to be zone specific.

I disagree.

Again, as stated before: The key press invokes an IMPLICIT play command in some situations. There it makes totally sense to use the provided zone specific params. Also note my new FR here: https://yabb.jriver.com/interact/index.php?topic=105541.0 which also REQUIRES MCC commands to be zone specific.

For me the current "send to window" approach is understandable because it is where you came from. BUT looking forward it is not the way to go. Zones should be regarded as individual playback units. And as such it MUST be possible to direct commands (no matter what they mean) to a specific zone.

All you would have to do is this: carry the zone params along with the command that is CAUSED by the initial MCC command and pass this until the command is FULLY evaluated.
That means, programmatically speaking:

struct MCCommand
{
    Zone* zone; // might be NULL (or the current zone)
    Command command; // would be the MCC command here
} mc_command;

So you basically STORE the provided zone as long as possible until the command is finally processed. In the case of an "enter" key (MCC command 27000, parameter 13) the resulting PLAY command - which might happen when you are over a playable file in theater view - shall also receive the initial zone info of the MCC command causing the playback to happen. This way any command goes the way it should!

I think the old paradigm "send to main window" should be trashed and looking forward you should really be much much more zone-aware everywhere!

[Matt]

Again, as stated before: The key press invokes an INPLICIT play command in some situations.

Well you can issue play commands in a zone-specific way.  But you can't issue keystrokes in a zone-specific way.

[masterjoe]

... But you can't issue keystrokes in a zone-specific way.

Right. This is the way it is currently. But is this a good solution if you follow my discussion closely? No.

This current approach is understandable but truely old-fashioned. And if you really care about thinking of a future for MC then you should change the current behavior. Because in my opinion almost EVERY command should be zone-aware. And it does make sense if you might have a look at my FR from my previous post.

Did you have a look at this? -> https://yabb.jriver.com/interact/index.php?topic=105541.0


INTERNALLY you could already create multiple windows which provide you with the zone-aware functionality that MC should have. These windows do not need to be visible until you really want to implement my feature request (see above). The window message handler of each window would execute commands ALWAYS in a zone specific way. So you could still send the command to a window - but it would be the right one for the targeted zone!

I must repeat myself to note that I can't understand the opposition here!

[blgentry]

Because I do MUCH more than just control MC with my remotes. I have a customly programmed Python-based home automation system where MC is only one part of many. I do not want to let MC dictate how I am doing things. I want my automation system to do that. It is very strongly context driven.

Great.

Therefore the generic approach using MCWS as middleware is the only way because my remote might send totally different NON-MC commands on the EXACT same keys of the remote! My system knows in which mode I am and directs the commands accordingly! My system is strictly context-aware! The mapping of any key of my IR is totally context-dependent.

Pretend for a moment that MC is not MC and instead it's a set top box.  How would you do it then?  You would send IR commands from your middleware's IR spitter to the set top box.  Because that's how the set top box is designed to be used.  Send IR commands to MC and it will react correctly in the ways it was designed to react to IR commands.

You have the head developer of MC right here in this thread telling you that keypress commands via MCC were not designed to be used this way.  Why not use IR from your home automation system?  Certainly it is capable of sending IR commands.  You can still be context aware and send IR instead of IP.

Brian.

[mwillems]

Right. This is the way it is currently. But is this a good solution if you follow my discussion closely? No.

This current approach is understandable but truely old-fashioned. And if you really care about thinking of a future for MC than you should change the current behavior. Because in my opinion almost EVERY command should be zone-aware. And it does make sense if you might have a look at my FR from my previous post.

Did you have a look at this?

FWIW, I think your approach would introduce issues for other folks, and sending keypresses instead of using purpose built commands seems like the old-fashioned method to me.  There are dedicated play and pause commands that do exactly what you need them to (every time) and are zone aware.  That's the modern and "correct" approach to the issue.  The idea that a weird kludge sending keypresses instead of using unequivocal commands is the "way forward" seems bizarre.

Making keypresses zone aware could also break other people's automation who expect the MCWS keypress to function the same way that, you know, pressing a key would function.  If it were made zone aware, it would have to default to the active zone, which would lead to some very confusing interactions for people sending "naked" keypresses.  I can't even imagine how that would interact with zoneswitch.

I'm not a dev, so it's not my call, but I think you've got an x/y problem.  There are almost certainly easier ways to achieve this particular goal that would work equally well without reinventing the entire automation framework that others rely on (bracketing out your other feature requests).

[masterjoe]

Great.

Pretend for a moment that MC is not MC and instead it's a set top box.  How would you do it then?  You would send IR commands from your middleware's IR spitter to the set top box.  Because that's how the set top box is designed to be used.  Send IR commands to MC and it will react correctly in the ways it was designed to react to IR commands.

You have the head developer of MC right here in this thread telling you that keypress commands via MCC were not designed to be used this way.  Why not use IR from your home automation system?  Certainly it is capable of sending IR commands.  You can still be context aware and send IR instead of IP.

Brian.

My system does not send specific IR codes but codes which are optimized for fast response. The codes indeed TOGGLE. MC would not be able to understand these toggling codes and interpret them wrongly. My automation system uses this toggling behavior anywhere to speed up the responsiveness of the system. That works just great!

So your suggestion is no solution for me.

I might ask: why does MC have zones and MCWS automation when I am forced to pretend MC is a SINGLE-SOURCE? Your suggestion implies that it is something good to disregard zones. Well, I think the opposite way.

MC not always had zones and thinking of MC as a set top box is the old-fashioned way. As far as I can understand why one might think so I am looking at this as the old paradigm. MC already HAS zones which makes it much more than just ONE set top box. In fact it can be MANY set top boxes. And now tell me that you want to control multiple set top boxes as if they are just a single one? Here is something profoundly wrong!

So no, I am sorry I must disagree again and come to the conclusion that you do not have fully grasped what these zones mean for MC and its use cases.

In programmer terms the discussion is about "are global variables better than object attributes". Currently you defend that global variables are the way to go. I don't think so now and will never think so in the future. MC is not a singleton, no single source. With its multiple zones it can be many MCs at the same time. And here something is not right with the current behavior of MCC commands!

[masterjoe]

FWIW, I think your approach would introduce issues for other folks, and sending keypresses instead of using purpose built commands seems like the old-fashioned method to me.  There are dedicated play and pause commands that do exactly what you need them to (every time) and are zone aware.  That's the modern and "correct" approach to the issue.  The idea that a weird kludge sending keypresses instead of using unequivocal commands is the "way forward" seems bizarre.

Making keypresses zone aware could also break other people's automation who expect the MCWS keypress to function the same way that, you know, pressing a key would function.  If it were made zone aware, it would have to default to the active zone, which would lead to some very confusing interactions for people sending "naked" keypresses.  I can't even imagine how that would interact with zoneswitch.

I'm not a dev, so it's not my call, but I think you've got an x/y problem.  There are almost certainly easier ways to achieve this particular goal that would work equally well without reinventing the entire automation framework that others rely on (bracketing out your other feature requests).

No - there would not be ANY problem regarding backwards compatibility. Because if NO zone is provided (and most users would not provide any zone) then the behavior is EXACTLY the same as it is now! No problems. Because currently the key presses are sent to the current zone anyway.

So there is no reason to think this would break backwards compatibility!

[mwillems]

No - there would not be ANY problem regarding backwards compatibility. Because if NO zone is provided (and most users would not provide any zone) then the behavior is EXACTLY the same as it is now! No problems. Because currently the key presses are sent to the current zone anyway.

So there is no reason to think this would break backwards compatibility!

They aren't "sent to the current zone anyway" because the keypresses can execute all sorts of commands many of which are zone agnostic or zone-specific (but not to the active zone), they don't just play and pause.  Keypresses can change the active zone, send media to other zones, or, in short, do anything that can be achieved through the UI by pressing keys.  Some of the things that keypresses do can't even be made to be zonespecific, and sending some of them to the "active zone" in all cases would break user expectations in some cases.

It just seems bizarre to try and reinvent the enter key when there's a nicely packaged "play" command just waiting for you.

[masterjoe]

They aren't "sent to the current zone anyway" because the keypresses can execute all sorts of commands many of which are zone agnostic or zone-specific (but not to the active zone), they don't just play and pause.  Keypresses can change the active zone, send media to other zones, or, in short, do anything that can be achieved through the UI by pressing keys.  Some of the things that keypresses do can't even be made to be zonespecific, and sending some of them to the "active zone" in all cases would break user expectations in some cases.

It just seems bizarre to try and reinvent the enter key when there's a nicely packaged "play" command just waiting for you.

If you have followed the discussion and figured out my use case you would see that I simply cannot invoke a "play" there.

Also I have said that ALMOST every MCC command should be zone aware. Not really ALL of them. I agree that some might simply discard the zone info if it is irrelevant.

So the discussion is about: There are SOME MCC commands which really COULD be zone aware and currently are not.
Looking at my FR (see above) it becomes even more obvious that there should be a change regarding future use cases for MC.

Again: I never said that ALL MCC shall be zone aware - but as many as possible!

And I can't see anything bizarre in what I am stating here. But I can see that many of you do not want to look at the whole picture regarding what zones are and how they can be used - now or in the future.

The "enter" key can mean multiple things in MC and with my "few buttons" remotes I like this behavior. Until the point where the zone info is simply discarded when it makes sense to use it. This is all it is about.

[blgentry]

Masterjoe we obviously have a huge communication barrier.  Part of what you say makes no sense (Toggle only commands are faster).  Your interpretation of what I was trying to say is way way off the mark.  I'm out of this conversation.  I wish you the best of luck.

Brian.

[masterjoe]

Masterjoe we obviously have a huge communication barrier.  Part of what you say makes no sense (Toggle only commands are faster).  Your interpretation of what I was trying to say is way way off the mark.  I'm out of this conversation.  I wish you the best of luck.

Brian.

Ok, thanks for your participation, anyways

Btw: Toggling codes make it easier for IR receivers to separate IR commands - and that indeed improves the "commands per second" rate a lot. My automation system is the master in my home as I said and it already solves a lot of jobs very very efficiently. The generic nature of this approach might be different from what most people "expect" such a system to be. But I am a software dev myself and always looking for the BEST + most flexible solution - even if that requires to go new ways. The problem I seem to be facing here is that you are not willing to go beyond the boundary of what is currently there.

[JimH]

[masterjoe]

http://ell.stackexchange.com/questions/78049/barking-up-a-tree-barking-up-the-wrong-tree/78053

Err, was that some kind of a joke regarding the "communication barrier" Well... *woof* *lol*

[Hendrik]

This discussion seems to go in circles, so lets keep it simple:
Like Matt explained above, they keystroke MCC command acts exactly like if it would be input on a keyboard. We do not currently plan to change that, as there is no concept of having "zone specific" keyboards, and no logic in MC to support such behavior.

If any commands that directly control a zone do not obey the zone parameter properly, please let us know and we'll fix those.
As others have noted, there are various commands that do not fit to a zone, so not every single command does in fact take a zone, and often it also doesn't make sense to do so.

[masterjoe]

This discussion seems to go in circles, so lets keep it simple:
Like Matt explained above, they keystroke MCC command acts exactly like if it would be input on a keyboard. We do not currently plan to change that, as there is no concept of having "zone specific" keyboards, and no logic in MC to support such behavior.

If any commands that directly control a zone do not obey the zone parameter properly, please let us know and we'll fix those.
As others have noted, there are various commands that do not fit to a zone, so not every single command does in fact take a zone, and often it also doesn't make sense to do so.

Ok, noted.

Now there seems to be something missing to control MC in the same simple way MCC commands allow that for a SPECIFIC zone.


One of the key players of this problem is that the theater view is NOT zone aware. This seems strange when EVERYTHING that can be played lands in one or the other zone.
So my question could also be:

How can I control WHERE (in which zone) a file becomes played when I am navigating using the theater view only?

(And I do not mean switching the zone but targeting a playback command for a specific zone - using theater view as the only input!)

Edit to add:
My FR, found here:
https://yabb.jriver.com/interact/index.php?topic=105541.0
would solve this case because zones would have their own theater view and their own targeted MCC etc. commands.

[Hendrik]

How can I control WHERE (in which zone) a file becomes played when I am navigating using the theater view only?

The top roller has a zone selector in Theater View, if you switch the zone there all further commands will be targeted at that zone.

Your other feature request is not very likely to happen. All our UI interfaces are singular, you don't get a Standard View per-zone either, so Theater View will not do that either. Thats not what Zones are meant to be.
The only thing that can be per-zone right now already is a detached display view, ie. one video output per zone, and users use that with great success (although probably not from theater view, which is designed to be a single control point on a single TV, not a managing interface for several distinct other playback screens).

[Matt]

Next build will have this little tweak:
Changed: Made Theater View respond to the MCWS/v1/Files/Current function.

That way you can select manually and issue a File/Current command to get the playlist back.

[masterjoe]

Next build will have this little tweak:
Changed: Made Theater View respond to the MCWS/v1/Files/Current function.

That way you can select manually and issue a File/Current command to get the playlist back.

Oh, good, this sounds promising. Will I find out which file / item is currently "selected", i.e. which file has the "selection box" around it?
Because knowing this it will indeed become possible to do whatever I want with the selected file!

If this is not currently possible please consider a MCWS command which allows to query / get the selected (selection box) file / item from Theater View at any time.
With this function I could also display some additional info about the currently selected file in my own widget which could be floating over Theater View.

Currently the selection at the "box cursor" in Theater View is totally unknown programmatically from "outside". Being able to know it I could also solve the case of this thread by manually speficying the correct zone with a play command which becomes then possible. However the command's result should clearly indicate whether the selection is playable or not (because it might be a view / subview etc.)! This way on "enter" I would query MC for what is currently selected in Theater View and then decide whether so send a "normal enter" key or whether to issue a play command for whatever zone.

In other words to make it clear:
It would be great to get the FULL playlist of all files currently displayed in Theater View but ADDITIONALLY to that I would like to be able to find out which of these files is currently selected by the "box cursor" and whether this item is playable (i.e. a file) or not.

EDIT:
Will ActiveFileOnly=1 return the "box selection" and ActiveFileOnly=0 return the full list?