Playback doesn't resume after Alert

There are so many SONOS threads, so not sure where this post belongs - however:

First of al thank you for your efforts on the plugin.

The doco says the plugin can be downloaded from the AltApp store but it’s not to be found in that store. So using this on a Vera 3:

PluginVersion 2.0-20136
Running 5 zones; proxy detected

All works pretty well. Slight problem - when saying an “Alert”.

  1. the current music/radio station stops
  2. the alert message is played
  3. the current music/radio station does not restart

Have attached a log of the sequence. It’s actually a text file, not a PDF, as you can’t upload text files, so need to rename it. Sonos log.txt.pdf (38.6 KB)

By they way it seems you have different logging types but GitHub does not describe or mention how to control the different types/levels.

On line 165 of the attached doc ie 6 lines up from the last line, you can see an error message. Now while I have multiple sonos units and their is a child for each in the UI, they are all powered off (at the switch) except one, that remains on constantly. So the error may be something to do with the grouping under these circumstances.

If I turn all the units on that were off, the same problem still occurs. I note that the icons for all the child devices all show just a square box with the word SONOS in it, except for the one that is powered on all the time. Previously they have shown a “picture” of the device.

So presumably related to units either being powered on or off at different times?

That’s a good indicator that you can just start a new thread.

Number one cause of this: not specifying the Duration parameter on the Alert action.

Your PDF document isn’t readable (but don’t repost it; I prefer formats other than PDF for logs and if we end up needing a log I’ll give you guidance).

I tried a PDF in landscape mode and it was still so heavily wrapped it was difficult to read.

On the call to “Alert”, the duration is specified.

What’s the source of the music playing at the time?

Can you try installing the hotfixes? Also, please set DesignatedMaster to 1 on the unit that remains powered all the time.

The same thing happens whether the alert is interrupting a mp3 or an online radio station.

I’ll install the hot fixes to Sonos-Vera-stable and get back to you. I suspect it’s related to the grouping when the other sonos players are powered off ie there is nothing active to group.

OK, I just added that you should set DesignatedMaster to 1 on that full-time device. You’re likely right… the selected masters are probably being powered off and it’s losing its source of network topology updates in the process. That’s exactly what that flag is meant to mitigate. Let’s give it a go.

That said, resuming streaming radio is a mixed bag. Works for some, not others. Always works when local media is streaming (i.e. when there’s a real queue). It’s just a Sonos thing, but hopefully yours will work.

OK that worked without installing any hot fixes - so yes posted in wrong spot earlier :upside_down_face:. Previously all of the Sonos units had “DesignatedMaster” showing blank. The always on unit has now been set to DesignatedMaster = 1. For those interested: have now gone from this error:

16:31:37.109   luup_log:229: Sonos: [debug] endSayAlert() restoring group structure after temporary group <0x2ddb3680>
16:31:37.110   luup_log:229: Sonos: [debug] endSayAlert() "RINCON_000E58DC7BBE01400" is coordinator of temporary group <0x2ddb3680>
16:31:37.111   luup_log:229: Sonos: [debug] endSayAlert() restoring group structure <0x2ddb3680>
16:31:37.111   luup_log:229: Sonos: [debug] endSayAlert() restoring member "RINCON_000E58DC7BBE01400" to nil <0x2ddb3680>
16:31:37.112   luup_log:229: Sonos: [debug] controlAnotherZone("RINCON_000E58DC7BBE01400","RINCON_000E58DC7BBE01400") <0x2ddb3680>
16:31:37.113   luup_log:229: Sonos: Task:run() task { name="234", owner=234 } failed: "[string \"--[[...\"]:3509: attempt to concatenate field 'GroupCoordinator' (a nil value)" <0x2ddb3680>

to fixed: “RINCON_000E58DC7BBE01400” is its own group coordinator

10:45:01.110   luup_log:229: Sonos: [debug] endSayAlert() restoring group structure after temporary group <0x2d659680>
10:45:01.111   luup_log:229: Sonos: [debug] endSayAlert() "RINCON_000E58DC7BBE01400" is coordinator of temporary group <0x2d659680>
10:45:01.112   luup_log:229: Sonos: [debug] endSayAlert() restoring group structure <0x2d659680>
10:45:01.113   luup_log:229: Sonos: [debug] endSayAlert() "RINCON_000E58DC7BBE01400" is its own group coordinator <0x2d659680>
10:45:01.116   luup_log:229: Sonos: [debug] endSayAlert() restoring saved playback contexts <0x2d659680>

Rigpapa thanks for the help on this.

it’s losing its source of network topology updates in the process

Any easy software solution to this?

DesignatedMaster is exactly that solution. When the plugin starts up, it chooses two units (that it can communicate with at that moment) to be topology masters, and the plugin subscribes to topology updates from these units. Unfortunately, there’s no network announcement when a unit is turned off or otherwise vanishes from the network, it’s just quietly removed from the topology at some future point (several minutes). If both units that happened to be chosen as masters are turned off within a short period, there will never be any notice that there are no masters left (it needs a topology notice to know they are missing). By adding DesignatedMaster to the algorithm, the plugin can be told which units are preferred over others as topology masters, and this is meant to ensure that at least one unit is always available in that role.

Yours is the first configuration I’ve run into that truly needs DesignatedMaster turned on. For the benefit of other readers, it should only be turned on for zones that are always powered, always available.

Of course, there’s no software way to determine what systems will be left on and which will not; there’s too much human in that choice. I suppose I could try to do something like accumulate uptime and prefer systems with larger sums, but when behavior changes, it would take a long time to adapt, and it’s not very transparent. The DesignatedMaster approach has the benefit of being very simple and reliable (and there’s lots of logging around the process, if you look at some of the startup messages).

Versions of the plugin earlier than 2.0 subscribed to topology updates from every zone. But this generated huge amounts of traffic and system overhead in networks with more than just a few players. You could get 64 topology announcements (within a second) if you grouped 8 players into a single group, because each player would send an update for each individual change of each player, including itself. You end up getting 8 of the same announcement 8 times. The Sonos UPnP API isn’t very efficient.

You should still install the hotfixes, as at least one is related to a change in the structure of the zone topology XML that popped up in a recent UK firmware release, and I’m not sure if that change is going to end up popping out to other locales later. There was also a services metadata handling bug that killed the ability to connect to some streaming services.

Unsure why it needs two masters? When the plugin starts up it will (in my case) presumably always find my one main unit always on.

Yours is the first configuration I’ve run into that truly needs DesignatedMaster turned on.

There is always someone not playing the game the way it should be. I suppose the log could issue some instructions, when the GroupCoordinator is found to be nil.

Even with designated masters, there is always a possibility of a master going away. If there was only one master and it went away, who would tell the others? :slight_smile:

My zone players don’t have power buttons. I’m not aware of any models that do. But then, there are quite a few models I don’t have, most of them in fact, because I am making no further investment in that overpriced hardware.

Also keep in mind that the plugin isn’t my original work. I’ve already spent… what… half a year?.. combing out old bugs, restructuring, reworking, optimizing… it’s far from done. But then, given that Sonos has all new firmware and new API, and this generation of Vera firmware is walking dead, it’s probably not worth the effort to drill out every bug in every boundary condition.

My zone players don’t have on/off buttons either. I have them connected to z-wave controlled power outlets. As you point out, the players are far to expensive to start with, so a few bucks saved here and there on the power consumption, all helps. Plus there is a small matter of climate change I really like to consider.

Talking about walking dead; openLuup works fine and the many hours I have put into writing my own plugins will not be lost because of akbooer’s great work. The Sonos app would be most welcome in the AltApp store. I appreciate your efforts on this, as I’m sure many others do too.