Sonos surround configuration not recognized

[Lameth75]

Hi Philippe,

I'm new to AirConnect, used airsonos until now and have to admit: Great work!

Unfortunately AirConnect only works for a part of my configuration. I have several Play:1 spreaded across my rooms in standalone and stereo configurations. Those speakers are recognized correctly. But there is also a surround configuration (Playbase + 2x Play:1) which isn't recognized. If I remove surround configuration all speakers are recognized as expected.

Do you have any idea how to find the source of this problem?

Thanks in advance for your help, Lameth

[philippe44]

When you just pair two PLAY:1 does it work? (it does for me - I can't have with a surround, I don't have one)

[olemartinorg]

I tried with two PLAY:3 and it works some times, and sometimes it doesn't. Looks like if you cold-start streaming sound to one of the speakers it will only play on that one (and if you cold-start playing to the other one in my case it wouldn't play anything at all). If Sonos were already playing something else (internet radio, for example) when you start streaming sound to one of the speakers it would interrupt the internet radio and play on both speakers (like expected).

[philippe44]

I'll try but as far as I remember from my other bridges and Sonos, you must stream to the group master and then it works fine, all others are playing in sync

[jhurliman]

I just tested this and am seeing the same result as @olemartinorg (or at least something close to it). I created a stereo pair and both speakers are showing up individually in AirPlay. When I stream to the non-master it plays fine, but only out of the one speaker. When I try to stream to the stereo master I hear nothing at all.

[philippe44]

I can only test groups (PLAY:3 with PLAY:5) which work as they should. I can't try anymore stereo pairs as my PLAY:1 have been stolen last year

[marco79cgn]

I solved both issues using a workaround for the stereo as well as the Playbar setup.

Stereo works for me all the time if I choose the correct speaker of the set (don‘t know whether this is the master, I just tried it). As soon as I choose the other (wrong) one a single time as Airplay target, stereo is broken, even when playing directly from the Sonos app afterwards (without Airplay!). When it‘s broken one time, it plays silence on the former correct speaker and it plays only on one speaker when chosing the other one (like described above by @jhurliman). If this happens, I could only solve this wrong behaviour by creating a group with another room in the Sonos app. Afterwards, it plays stereo correctly again. In order to avoid this issue completely in the future, I created a config.xml file (by starting with parameter „-i config.xml“). In the resulting file, I simply deactivated the wrong player which is causing the issue (after accidentally selecting it once) so that it won‘t show up as an AirPlay option anymore. Doesn‘t make sense anyway for a stereo pair to have two Airplay options for left and right. ;)

In my surround setup consisting of a Playbar, a Sub and two Play:1 (rears), I also disabled everything except the Playbar in the config.xml.

[jhurliman]

Wow, interesting! This sounds like a Sonos bug if a third party UPnP connection can break a stereo pair. I’ll follow the advice above.

You can find out which speakers to stream to by querying /status/topology and filtering for speakers with coordinator=true

[marco79cgn]

Thanks, so it's the coordinator of the two which I/you have to choose. :)

I tested it a few times and can reproduce this behaviour every time. By the way, once a stereo pair is broken, you can only fix it by joining this pair to a group in the Sonos app - but the master of the group has to be another room/speaker! As long as the broken stereo device is the leader of the group, it will keep playing only on one speaker.

Besides this behaviour (which I can perfectly work around), AirConnect works very smooth on my Raspberry Pi 3. It's way better and stable than the former AirSonos for example (which only ran on a Mac anyway as far as I can remember).

By the way, another advantage of the config file is that you can rename the AirPlay targets of all your speakers/rooms (in my case, every player started with the IP address per default).

[jhurliman]

Will separating the stereo pair and recreating it fix the problem? I’m wondering how you fix it if you only have two speakers.

[marco79cgn]

Yes, I just tried it, it works as well by recreating the stereo set.

Unfortunately this breaks your Trueplay setup. And as I learned just now, it's not yet possible to calibrate Trueplay using the iPhone X.

[jhurliman]

@marco79cgn I'm in the exact same boat :-|. Thanks for the troubleshooting help though! This ticket can probably be closed, although maybe it's worth mentioning in the README somewhere?

[philippe44]

I will see if I can detect slave members of a Sonos group and not add them to players then

[philippe44]

Done in 0.1.4.0

[edit]: added group volume management as well

[marco79cgn]

Thanks, that was quick! I tested it with 0.1.4.1 and started from scratch. I noticed the following things:

1. If there is a group of players, only the coordinator/master of the group is shown as AirPlay target (might be a bug or a feature, but is different to the previous version). Choosing it will play on the whole group (as expected).
2. Point 1 leads to players not being added to the config.xml file when generating it for the first time. So you might add to the readme that one should resolve all existing groups before generating a config for the first time.
3. Confirmed: only the master of a stereo group is added at all. The other one doesn't even show up.
4. In a surround setup (Playbar, Sub, 2x Play:1), all players are added, one should still disable all except the Playbar.

[philippe44]

The fact that only the master is shown is a feature to avoid breaking the group by accidentally playing on a slave. Now if you undo a group, periodic detection will add the new players. If you have used -I for config file auto update, they will appear in there as well. If you create a group, the slave player will also be removed from the airplay target at next detection cycle (they are never removed from the config file) I will add a note to the README. For a sub configuration, then I don't know. I'd need a log of what is the group config. Do you have a way to execute DeviceSpy (Windows tool)

[marco79cgn]

Thanks for the explanation.

There is a difference between a group of players/rooms and a stereo set. In the former versions of airconnect, it was no problem to choose any player/room of an existing group (as long it was NOT the slave of a stereo pair at the same time!). If you did so, the chosen player was correctly removed from the former group and started playing the AirPlay source, while the other former group members have been playing the same thing as before.

Examples (Airconnect before 0.1.4.0):

Scenario 1: Imagine a group playing something on Spotify 1 x Play:1 bathroom (group master) 1 x Play:1 kitchen If you chose the kitchen as Airplay target from your phone trying to play a podcast, the kitchen has been removed from the group (since it's not the master) and the bathroom kept playing Spotify. If you chose the bathroom as a target instead, the podcast was played in both bathroom and kitchen (since bathroom is the master of the group). Of course it's not possible in the AirPlay menu to know which of the devices is the master of a group. But that's another topic.

Scenario 2: Imagine a group playing something on Spotify 1 x Play:1 Bathroom (group master) 2 x Play:1 Kitchen (Stereo set) Behaviour was the same as scenario 1, except if you chose the slave of the kitchen stereo set - then it was broken.

To make a long story short, with the newer versions of Airconnect, you can only connect the whole group. This is also perfectly fine for me, I just wanted to explain the difference.

I'm running Mac OS X, but I have a Parallels VM running Windows 7. So I could give DeviceSpy a try. What exactly do I have to do?

[philippe44]

Yes, the scenario is correct. I thought that breaking the group was not a good thing. Now, if this is a problem and some would prefer to break the group when purposely sendign to a slave (although I'm not sure how to know which one is the salev which one is the master), I can always make that an option, but it does not seem right to me and I always prefer to keep number of options limited (they justy confuise users and make support more painful :)) For DeviceSpy, you'd need to select the "ZoneGroupTopoogy" schema of one of your players, expand it and double click on "GetZoneGroupState" and invoke the action; It will return an xml payload that describe the syntax of a surround system so I can detect it. Currently the logic is: for each "ZoneMember" if it's member of a ZoneGroup of which it's not the controller, then it's a slave so ignore it.

[marco79cgn]

Here we go:

<ZoneGroups>
    <ZoneGroup Coordinator="RINCON_5CAAFD055ABA01400" ID="RINCON_5CAAFD055ABA01400:166">
        <ZoneGroupMember UUID="RINCON_5CAAFD055ABA01400" Location="http://192.168.178.102:1400/xml/device_description.xml" ZoneName="Küche" Icon="x-rincon-roomicon:kitchen" Configuration="1" SoftwareVersion="39.2-47040" MinCompatibleVersion="38.0-00000" LegacyCompatibleVersion="25.0-00000" BootSeq="163" WirelessMode="1" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="2467" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="1" SecureRegState="3" VoiceState="0"/>
    </ZoneGroup>
    <ZoneGroup Coordinator="RINCON_B8E937E357EA01400" ID="RINCON_B8E937E357EA01400:216">
        <ZoneGroupMember UUID="RINCON_B8E937E357EA01400" Location="http://192.168.178.16:1400/xml/device_description.xml" ZoneName="Bad" Icon="x-rincon-roomicon:bathroom" Configuration="1" SoftwareVersion="39.2-47040" MinCompatibleVersion="38.0-00000" LegacyCompatibleVersion="25.0-00000" BootSeq="1262" WirelessMode="1" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="2467" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="1" SecureRegState="3" VoiceState="0"/>
    </ZoneGroup>
    <ZoneGroup Coordinator="RINCON_B8E937E35CD201400" ID="RINCON_B8E937E35CD201400:96">
        <ZoneGroupMember UUID="RINCON_B8E937E35CD201400" Location="http://192.168.178.147:1400/xml/device_description.xml" ZoneName="Schlafzimmer" Icon="x-rincon-roomicon:masterbedroom" Configuration="1" SoftwareVersion="39.2-47040" MinCompatibleVersion="38.0-00000" LegacyCompatibleVersion="25.0-00000" ChannelMapSet="RINCON_B8E937E35CD201400:LF,LF;RINCON_B8E937B7818401400:RF,RF" BootSeq="1242" WirelessMode="1" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="2467" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="1" SecureRegState="3" VoiceState="0"/>
        <ZoneGroupMember UUID="RINCON_B8E937B7818401400" Location="http://192.168.178.52:1400/xml/device_description.xml" ZoneName="Schlafzimmer" Icon="x-rincon-roomicon:masterbedroom" Configuration="1" Invisible="1" SoftwareVersion="39.2-47040" MinCompatibleVersion="38.0-00000" LegacyCompatibleVersion="25.0-00000" ChannelMapSet="RINCON_B8E937E35CD201400:LF,LF;RINCON_B8E937B7818401400:RF,RF" BootSeq="1004" WirelessMode="1" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="2467" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="5" SecureRegState="3" VoiceState="0"/>
    </ZoneGroup>
    <ZoneGroup Coordinator="RINCON_5CAAFDAE9CC401400" ID="RINCON_5CAAFDAE9CC401400:263">
        <ZoneGroupMember UUID="RINCON_5CAAFDAE9CC401400" Location="http://192.168.178.151:1400/xml/device_description.xml" ZoneName="Wohnzimmer" Icon="x-rincon-roomicon:living" Configuration="1" SoftwareVersion="39.2-47040" MinCompatibleVersion="38.0-00000" LegacyCompatibleVersion="25.0-00000" HTSatChanMapSet="RINCON_5CAAFDAE9CC401400:LF,RF;RINCON_5CAAFD4D812001400:LR;RINCON_5CAAFD7CE86801400:RR;RINCON_949F3E400B7201400:SW" BootSeq="420" WirelessMode="1" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="2467" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="1" SecureRegState="3" VoiceState="0">
            <Satellite UUID="RINCON_5CAAFD4D812001400" Location="http://192.168.178.29:1400/xml/device_description.xml" ZoneName="Wohnzimmer" Icon="x-rincon-roomicon:living" Configuration="1" Invisible="1" SoftwareVersion="39.2-47040" MinCompatibleVersion="38.0-00000" LegacyCompatibleVersion="25.0-00000" HTSatChanMapSet="RINCON_5CAAFDAE9CC401400:LF,RF;RINCON_5CAAFD4D812001400:LR" BootSeq="709" WirelessMode="0" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="5240" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="5" SecureRegState="3" VoiceState="0"/>
            <Satellite UUID="RINCON_5CAAFD7CE86801400" Location="http://192.168.178.93:1400/xml/device_description.xml" ZoneName="Wohnzimmer" Icon="x-rincon-roomicon:living" Configuration="1" Invisible="1" SoftwareVersion="39.2-47040" MinCompatibleVersion="38.0-00000" LegacyCompatibleVersion="25.0-00000" HTSatChanMapSet="RINCON_5CAAFDAE9CC401400:LF,RF;RINCON_5CAAFD7CE86801400:RR" BootSeq="625" WirelessMode="0" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="5240" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="5" SecureRegState="3" VoiceState="0"/>
            <Satellite UUID="RINCON_949F3E400B7201400" Location="http://192.168.178.100:1400/xml/device_description.xml" ZoneName="Wohnzimmer" Icon="x-rincon-roomicon:living" Configuration="1" Invisible="1" SoftwareVersion="39.2-47040" MinCompatibleVersion="38.0-00000" LegacyCompatibleVersion="25.0-00000" HTSatChanMapSet="RINCON_5CAAFDAE9CC401400:LF,RF;RINCON_949F3E400B7201400:SW" BootSeq="196" WirelessMode="0" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="5240" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="5" SecureRegState="3" VoiceState="0"/>
        </ZoneGroupMember>
    </ZoneGroup>
</ZoneGroups>

ZoneName "Schlafzimmer" is my stereo set, "Wohnzimmer" is the surround set (Playbar, Sub and 2x Play:1).

I guess the easiest solution would be to ignore all ZoneGroupMember that have the flag

Invisible="1"

don't you think? This would work for stereo sets as well as surround sets.

[philippe44]

Unfortunately, invisible does not apply for normal groups, so if I want to only present masters, I cannot rely on this attribute. But I'm an idiot as the only thing I have to check is that the detected player is a coordinator. On my previous version, I confused a bridge with a player, hence I thought filtering would be more complicated. But bridges are eliminated earlier in the detection process

Try 0.1.4.2

[marco79cgn]

Just perfect! Version 0.1.4.2 works as it should. Thanks a lot! 👍

pi@raspberrypi:~/airconnect $ ./airupnp-arm-0.1.4.2 -l 250:500 -i config.xml
[20:48:41.054566] main:1213 Starting airupnp version: v0.1.4.2 (Dec 11 2017 @ 11:27:42)
[20:48:41.055029] main:1221 no config file, using defaults
[20:48:41.057672] Start:996 Binding to 192.168.178.50:49152
[20:48:56.063368] AddMRDevice:888 [0x87ad4]: adding renderer (192.168.178.16 - Sonos PLAY:1)
[20:48:56.121302] AddMRDevice:888 [0x897dc]: adding renderer (192.168.178.151 - Sonos PLAYBAR)
[20:48:56.185946] AddMRDevice:888 [0x8b4e4]: adding renderer (192.168.178.102 - Sonos PLAY:5)
[20:48:56.255168] AddMRDevice:882 [0x8d1ec] skipping Sonos slave 192.168.178.29 - Sonos PLAY:1
[20:48:56.330142] AddMRDevice:882 [0x8d1ec] skipping Sonos slave 192.168.178.93 - Sonos PLAY:1
[20:48:56.399494] AddMRDevice:888 [0x8d1ec]: adding renderer (192.168.178.147 - Sonos PLAY:1)
[20:48:56.460249] AddMRDevice:882 [0x8eef4] skipping Sonos slave 192.168.178.100 - Sonos SUB
[20:48:56.549779] AddMRDevice:882 [0x8eef4] skipping Sonos slave 192.168.178.29 - Sonos PLAY:1
[20:48:56.744035] AddMRDevice:882 [0x8eef4] skipping Sonos slave 192.168.178.93 - Sonos PLAY:1
[20:48:56.813556] AddMRDevice:882 [0x8eef4] skipping Sonos slave 192.168.178.100 - Sonos SUB
[20:48:56.883184] AddMRDevice:882 [0x8eef4] skipping Sonos slave 192.168.178.52 - Sonos PLAY:1
[20:48:56.989538] AddMRDevice:882 [0x8eef4] skipping Sonos slave 192.168.178.52 - Sonos PLAY:1

[Lameth75]

Wow, looks great! Thanks for your great support, Philippe!👍🏻

There is just one thing which would make your project even greater ... in my eyes😉: Now we are in a state where only coordinators are exported via AirPlay. Together with the auto scan feature it works great so that players disappear after they became part of a group and reappear after they where removed from group. Even if the coordinator changes within one group, it should be handled without a problem.

As now there is only one device presented per room, what about using \<roomName> instead of \<friendlyName> as default \<name>? The benefit would be that the AirPlay name would be shorter and would correspond the Sonos room name without the need to modify any config files. What do you think?

[philippe44]

Like this (1.4.3)?

[marco79cgn]

Just perfect. 🥇

Goodbye config.xml!

pi@raspberrypi:~/airconnect $ ./airupnp-arm -l 250:500
[23:51:57.307945] main:1213 Starting airupnp version: v0.1.4.3 (Dec 11 2017 @ 14:34:08)
[23:51:57.308204] main:1221 no config file, using defaults
[23:51:57.359748] Start:996 Binding to 192.168.178.50:49153
[23:52:12.050742] AddMRDevice:888 [0x87bdc]: adding renderer (Küche)
[23:52:12.370149] AddMRDevice:888 [0x898e4]: adding renderer (Wohnzimmer)
[23:52:12.406218] HandleStateEvent:326 [0x898e4]: UPnP Volume local change 29
[23:52:12.465525] AddMRDevice:888 [0x8b5ec]: adding renderer (Bad)
[23:52:12.488851] HandleStateEvent:326 [0x8b5ec]: UPnP Volume local change 14
[23:52:12.523466] AddMRDevice:888 [0x8d2f4]: adding renderer (Schlafzimmer)
[23:52:12.538466] HandleStateEvent:326 [0x8d2f4]: UPnP Volume local change 14

[Lameth75]

Thanks for version 1.4.3 and thanks for testing, Marco. After taking a look at Marcos output it seems that AirConnect works exactly the way I expected it. 👍🏻

[philippe44]

if this is ok for you, would you mind closing the issue? I'm trying to keep things tidy ;-)