Error when adding Connect to speaker group

[peyronson]

Hi Been testing your script as a daemon on my Sonolgy NAS, and noticed the following;

When adding the Sonos device (ZP90/Connect) controlling the Yamaha reciever to a new or existing group of speakers, starting with another Sonos device, the script fails to correctly identify the playstatus of the Yamaha-connected device. This does not happen if you create a group starting with the device connected to the reciever.

Is this a known issue? Can it be fixed? Apart from this bug the script is worlking flawlessly.

[michaelotto]

I'll look into that, thanks for the heads up. The script does nothing much but wait for notifications from the Sonos devices, so this may be unfixable, but I'll have a try.

[michaelotto]

I just tried and cannot reproduce this. Here's what I do:

• Start playing a tune in room 1 (Sonos 1)
• Add room 2 (Sonos Z90/Connect with Yamaha Receiver) to the room 1 zone (grouping)
• Press "Done" => The Yamaha connected to the room-2-Sonos switches on and starts playing.

Did I miss something? Please look into the log files to see what was recognized. Once the rooms are connected, the script produces these log lines

2015-04-15 16:33:35.347634 SONOS play status: PLAYING Setting Yamaha MAIN:PWR to On (was: Standby) Setting Yamaha MAIN:VOL to -20.0 (was: -30.5) Setting Yamaha MAIN:SOUNDPRG to 5ch Stereo (was: Standard) Setting Yamaha MAIN:INP to AV1 (was: HDMI2)

[peyronson]

Yes, that's what I'm experiencing too. The bug only reveals itself if adding room 2 to a group from room1 while room 1 is paused. At the moment room 2 is added to the paused group the script logs this action as status: PLAYING, although music is in fact paused. And from that point on, no play/pause action in the group is picked up by the script.

2015-04-15 21:11:01.001976 SONOS play status: STOPPED <=== Room 1 paused 2015-04-15 21:11:12.114505 SONOS play status: PLAYING <=== This is logged at moment of adding room 2

Taking room 2 back out of the group solves the problem however, and the script returns to function properly.

It's not a major issue, but can sometimes be a little annoying.

[jcbass]

Michael, I really appreciate you posting this script. It was exactly what I was looking for.

I'm also having the issue where a grouped Connect does not detect the play command, and can reproduce. I have to ungroup the Connect and then re-group into a group that is already playing for the script to see status changes.

Like the above comment, when you are in the error condition (by adding Connect to a paused group), the script simply does not log any Playing/status updates.

Can anything be done to the script to detect this condition, or is this an issue with soco?

[michaelotto]

I've looked into this and I'm afraid there's little I can do.

The problem appears whenever the Connect gets added to a group and is itself not the "master" of this group, meaning that the room with the Connect is not the one you add other rooms to, but the room with the Connect itself is added to another room.

It also doesn't matter whether the "master" room is paused or not. Even if it is playing - subsequent play state changes of the group are not reported to the "non master" room subscribers (of which the sonos-monitor.py is one). This is probably due to the mesh architecture of the Sonos devices - the master room propagates just the music stream to its slaves, but not its states.

This is annoying, but the "solution" is simple: When grouping rooms, go to the room with the Connect in it and add the other rooms to this room, not the other way around.

Could you try - does this solve your issues?

[michaelotto]

I've looked further into this and, well ... there would be a way to solve this ...

But this would be a major rewrite. There is in fact a way to find out if the Connect is the slave in a group. One would have to re-subscribe to the group's master and listen to its events. Once the group is split, one would have to re-subscribe to the Connect again.

I'm currently looking into this.

[michaelotto]

Ok, last note: Unfortunately I cannot recognize if the group is split again - there is just no event triggered with the group master. So even if I would provide a fix, after splitting the group, one would be monitoring the wrong device -the group master- and the monitoring service would be pointless.

The only solution then would be to handle two subscriptions simultaneously - one steady one to the Connect and an eventual one to a possible zone master. But that would require a much more complicated logic and is beyond the scope of this little project.

Perhaps if I suffer from severe boredom in the future ...

[jcbass]

Thanks for the info Michael – it’s at least very helpful to understand the issue so I can work around it.

A suggestion. How about an option to work in “promiscuous” mode? Power-on the receiver if any Sonos device started playing. Easier?

[michaelotto]

Not really. Handling multiple subscriptions simultaneously requires threading as waiting for an event blocks the individual thread. It's all possible but would result in an entirely different script :-)

[mlamoure]

I was wondering if any new solutions to this problem have presented themselves since the original finding? Does SoCo offer any easy way to fix? I'm experiencing this a lot as my Connect is almost always grouped with other rooms of my house. Greatly enjoy the script when it works, though!

[mlamoure]

note: I've also modified (very poorly) your script to work with my Onkyo receiver.

[michaelotto]

No news from my side.

A related question to the crowd here: The Play-Pause-problem with this script only occurs when grouping the Connect with other Sonos players. But I have given this up completely, because there is an about 0.5 sec lag between the grouped players then, which makes the "synchronized" group sound horrible.

This is because Sonos cannot know or control the processing time of the receivers connected to the Connect. And unfortunately, one cannot determine the delay in the configuration of the Connect (which has been a feature suggestion for years).

In a nutshell: Grouping of the Connect doesn't work for me anyway. How come anybody wants this? ;-)

[mlamoure]

Wow, that's terrible. I don't experience this as all. Generally I'm always grouped with two other rooms in my house. Is your connect behind or ahead of the other sonos units? Could your AVR be tweaked to be in sync?

[michaelotto]

The Yamaha needs about 0.3-0.5 sec for processing (even in "direct" mode). So it's always behind.

And because of that I cannot tweak the sync on the Yamaha ("process faster!") side. It has to be done on the Sonos side.

But as a workaround, as a stated above, start the group from the Connect player and connect the other rooms to the Connect, not the other way around. This way, the Play-Pause-detection works.

[thehigherlife]

@mlamoure would you provide your onkyo modifications?

[mlamoure]

@thehigherlife Sure. I am not using this code any longer, but you are welcome to take a look.

sonos-monitor.py.zip