Against my better judgement I updated to this new version. The volume controls are improved (are they going to put the EQ back onto that screen?). I tested out my main issue, I.e. the speakers dropping in and out when tracks change and when rooms are added. Adding 1 room at a time, 3 rooms worked together including when I changed tracks. However, when I added a 4th room it all fell apart - silence, then one room resumed then dropped out, then another room came back on but missing out every other beat. It sounded like a pneumatic drill. I started again and only one room played until it too dropped out. So it’s great to have better volume controls but what good is that if the system at best seems to play only every other note!!!
What you’re describing is not a Sonos App issue - the App itself is only a ‘remote’ control. It is not a ‘player’ - I can group 10 rooms and play audio to all and close my Sonos App and even power off the mobile device and the playing audio continues without the App. If your speakers are not doing that then it’s more likely a local network issue, rather than anything App-related.
And it could be a speaker firmware issue as that is also being updated along with the app… the only thing that probably hasn’t changed for most people *is* the network. Your continual assertion that the app works and it’s everyone else’s network that’s at fault is pretty tiresome.
16.3 speaker code completely messes up the indexing of any album where the artist and album artist don’t match, so compilations are totally unusable now… no doubt that’s a network issue too?
I’m glad your limited use case is working for you, but please stop trying to dismiss other people’s issues as network all the time. The app and firmware are far from perfect.
And it could be a speaker firmware issue as that is also being updated along with the app… the only thing that probably hasn’t changed for most people *is* the network. Your continual assertion that the app works and it’s everyone else’s network that’s at fault is pretty tiresome.
16.3 speaker code completely messes up the indexing of any album where the artist and album artist don’t match, so compilations are totally unusable now… no doubt that’s a network issue too?
I’m glad your limited use case is working for you, but please stop trying to dismiss other people’s issues as network all the time. The app and firmware are far from perfect.
I don’t think it’s the Sonos firmware as that would not explain why 10 Sonos rooms happily stay firm/grouped and play audio here on my own Home mesh network, as seen in the attached recording that I made a few moments ago (UK London time).
@Ian_S,
If the Sonos speakers are dropping out - it most certainly is not the Sonos App and the firmware remains solid for my setup, so that definitely infers there’s a network issue involved somewhere in the mix, whether that is the LAN or the WAN connection, I can’t say. However that’s definitely the places I would start to look at first and there’s plenty of advice in the community here and within the Sonos support pages to help a user investigate those sort of issues - whether you find the posts tiresome, or not, the facts speak for themselves and ignoring them is unlikely going to resolve the issue.
Here are s few Sonos links to perhaps help get @BRJ started…
Just because some function works for you, does not mean that the code is perfect or will work the same for everyone else. It’s a really flawed assertion. The new app exercises new code in the firmware on the speakers. Sonos have chosen to use this different path so it’s up to them to get it working in the same scenarios (beyond just yours, and a few others) where the old code paths still function. We know they still function as the act of switching to a 3rd party controller which doesn’t use the new code, will suddenly cause broken systems to function again. (Barring the stuff that can only be done from the Sonos app.)
If the networks of so many people were truly broken, 3rd party controllers would also be broken and wouldn’t work either.
If someone has changed their network and has issues, then fine, they should investigate, but when the only changes come from Sonos and stuff stops working, but comes back to life when controlled the old way, I think it’s a much safer bet to assume it’s the new Sonos code in the app AND speakers that is at fault. And if that new code has exposed much worse support for mDNS than uPnP in a lot of people’s home networks, then maybe they made a bad decision in going down that route with the new app and firmware.
People didn’t ask Sonos to re-write their code. People bought something that worked and now doesn’t as a result purely of Sonos changing something. Sonos need to fix it and not expect people to tear their home networks apart to suit Sonos.
Just because some function works for you, does not mean that the code is perfect or will work the same for everyone else. It’s a really flawed assertion. The new app exercises new code in the firmware on the speakers. Sonos have chosen to use this different path so it’s up to them to get it working in the same scenarios (beyond just yours, and a few others) where the old code paths still function. We know they still function as the act of switching to a 3rd party controller which doesn’t use the new code, will suddenly cause broken systems to function again. (Barring the stuff that can only be done from the Sonos app.)
If the networks of so many people were truly broken, 3rd party controllers would also be broken and wouldn’t work either.
If someone has changed their network and has issues, then fine, they should investigate, but when the only changes come from Sonos and stuff stops working, but comes back to life when controlled the old way, I think it’s a much safer bet to assume it’s the new Sonos code in the app AND speakers that is at fault. And if that new code has exposed much worse support for mDNS than uPnP in a lot of people’s home networks, then maybe they made a bad decision in going down that route with the new app and firmware.
People didn’t ask Sonos to re-write their code. People bought something that worked and now doesn’t as a result purely of Sonos changing something. Sonos need to fix it and not expect people to tear their home networks apart to suit Sonos.
Just to reiterate - the controller Apps, whether engineered by Sonos, or a 3rd-party, are ‘remotes’, not ‘players’ and they can be fully closed after the playback begins on a single room, or a group of devices.
If the rooms either then begin to ungroup, or drop their audio, as mentioned, it’s not going to be App related. The firmware on the speakers is going to be the same on my speakers, your own and BRJ’s too (assuming all are up-to-date). The only difference that’s obvious is the LAN/WAN connection - so I would always start there to begin to find the issues, particularly when the App and speaker firmware is working for other people.
If you want to ignore that advice then that’s your prerogative, but I’m entitled to show the evidence to a user and provide helpful links. If you/they don’t find it helpful then ignore it, or at the very least take up the issues seen with your own systems and report them to Sonos Support via this link instead…
https://support.sonos.com/s/contact
In my view though, based on the evidence seen here, I believe the suggestions to try to resolve such issues are (still) valid.
You’re missing the point.
The speakers are running two discovery methods now, and probably API’s, the old well tested and trusted uPnP methods and the newer, clearly not so trusted mDNS route. Old Sonos S2 (if you’re on pre 16.3 firmware) and 3rd party products rely on the old uPnP methods to tell the speakers what to do, and the speakers when used in that way will keep in contact the old way and seem to work.
The new Sonos S2 app uses the mDNS methods which are not used by 3rd party apps, and clearly have a few issues.
The new app also relies (wrongly as Sonos are attempting to fix it) on internet connectivity when it doesn’t need it. So fails to instruct the speaker firmware correctly to do stuff if it can’t get the right online answer. So if you use the new app and have problems things look much worse.
Now, some of this could well be of Sonos’ own making especially if you have a mix of WiFi and Sonosnet connected speakers as then it’s up to Sonos speaker firmware to correctly relay mDNS broadcast packets around both internally on the hidden Sonos network and then also to push mDNS packets onto the WiFi/Ethernet they are connected to for non-Sonosnet speakers to get the required information from Sonosnet speakers. There’s a LOT of scope there to F it up. Plenty of more established home network companies have screwed that up too.
It’s not the users fault that they could be running this mix. Sonos will forget you setup your system choosing WiFi over sonosnet, and will happily add it automatically just because you plugged in an ethernet cable at some point.
In your case you have made sure you have no Sonosnet, and probably have anything wired into the core of your network. You may also have lucked into a router supplier who has done a better job of mDNS support. So yes it works for you, but only because you’ve hit a sweet spot in a lot of code, much like Mr. Spence’s home no doubt. Others are less fortunate, but that doesn’t mean that the Sonos code works, and that it is their network that is at fault.
“Added mute buttons for individual products in Group Volume controls”
Are you seeing these? I can’t see these in Android or iPad app. In the 16.1 there was a mute icon on the left but I can’t see it in similar position. There is just the speaker icon in that group UI.
is that somewhere else now?
When you adjust the group volumes, tap the speaker icon on the left of the Sonos speaker slider line you wish to mute.
Ok, now I think I see what the issue still is:
- A: when the Now Playing screen is whole display size, when I tap on the speaker icon on the left, it only mutes all. It does not bring up the individual volume controls. It does bring them up in the 16.1 app. I was expecting it to be available also in this screen.
- B: when the now playing component is small in the bottom of the screen I can tap on the speaker icon. It mutes and also brings up the volume control for the individual grouped speakers. I can mute individual speaker in this screen.
It probably is a firmware issue if it works for others also in scenario A. For me it looks that it’s only been implemented in the small Home Screen component.
Yes, that’s how I see it at the moment too - it's probably ‘by design’ for the time being, but I would like to see the option to mute individual rooms on the "Output Selector/Room Grouping Screen” aswell.
Not sure if we’re all at crossed purposes or saying the same things but I’ll go anyway based on what I’m seeing when playing grouped speakers:
On BOTH the full Now Playing screen AND the reduced Now Playing area at the bottom of the screen, when I move the volume slider or tap the speaker to mute, I get ALL grouped speaker sliders appearing, allowing me to adjust or mute each individual speaker.
So all working as it should.
Are you saying you are seeing something different?
Not sure if we’re all at crossed purposes or saying the same things but I’ll go anyway based on what I’m seeing when playing grouped speakers:
On BOTH the full Now Playing screen AND the reduced Now Playing area at the bottom of the screen, when I move the volume slider or tap the speaker to mute, I get ALL grouped speaker sliders appearing, allowing me to adjust or mute each individual speaker.
So all working as it should.
Are you saying you are seeing something different?
It’s the same thing that I see. 
I just would like to see the option to mute individual rooms on the "Output Selector/Room Grouping Screen” aswell.
The workaround when on that screen is to slide the rooms volume control to zero. See attached.
Hi @Ian_S, kudos for a good summary of the firmware issues associated with the new APIs. Adding a bit of technical color: beyond the switch from SSDP to mDNS, there is the pervasive use of TLS and websockets. The old APIs and the new APIs exist side-by-side (for now) in the device firmware; the new APIs are only exercised by the new Sonos app.
Anyone curious ought to read the fabulous article from Andy Pennel “What happened to the Sonos app? A technical analysis” here …
https://www.linkedin.com/pulse/what-happened-sonos-app-technical-analysis-andy-pennell-wigwc
BREAKING NEWS! Andy Pennel published a new article yesterday, documenting his experience with disappearing Sonos devices ...
https://www.linkedin.com/pulse/new-sonos-app-three-months-later-andy-pennell-vozoc
At the risk of stating the obvious: Andy Pennel has networking and Sonos-specific knowledge that is second-to-none outside of Sonos engineering. I would love to think that someone of Andy’s stature clearly documenting app/firmware issues would establish once and for all that these are problems … sadly, I doubt that is the case.
@BRJ,
You might perhaps find this thread useful too, even though it’s an old post by Staff, it’s still has a lot of helpful pointers that can maybe considered…
@BRJ,
You might perhaps find this thread useful too, even though it’s an old post by Staff, it’s still has a lot of helpful pointers that can maybe considered…
Thanks. I’ll have a work through this.
Today, we are moving to the new update 80.06.04…… My favorites are disorganized, some no longer work, some radio stations are inaccessible AND it is impossible to search in the “Radioplayer” service
Fed up!!!!!!
Today, we are moving to the new update 80.06.04…… My favorites are disorganized, some no longer work, some radio stations are inaccessible AND it is impossible to search in the “Radioplayer” service
Fed up!!!!!!
I’d suggest logging out of the app, closing it, re-opening the app and logging back in again.
You’re missing the point.
The speakers are running two discovery methods now, and probably API’s, the old well tested and trusted uPnP methods and the newer, clearly not so trusted mDNS route. Old Sonos S2 (if you’re on pre 16.3 firmware) and 3rd party products rely on the old uPnP methods to tell the speakers what to do, and the speakers when used in that way will keep in contact the old way and seem to work.
The new Sonos S2 app uses the mDNS methods which are not used by 3rd party apps, and clearly have a few issues.
The new app also relies (wrongly as Sonos are attempting to fix it) on internet connectivity when it doesn’t need it. So fails to instruct the speaker firmware correctly to do stuff if it can’t get the right online answer. So if you use the new app and have problems things look much worse.
Now, some of this could well be of Sonos’ own making especially if you have a mix of WiFi and Sonosnet connected speakers as then it’s up to Sonos speaker firmware to correctly relay mDNS broadcast packets around both internally on the hidden Sonos network and then also to push mDNS packets onto the WiFi/Ethernet they are connected to for non-Sonosnet speakers to get the required information from Sonosnet speakers. There’s a LOT of scope there to F it up. Plenty of more established home network companies have screwed that up too.
It’s not the users fault that they could be running this mix. Sonos will forget you setup your system choosing WiFi over sonosnet, and will happily add it automatically just because you plugged in an ethernet cable at some point.
In your case you have made sure you have no Sonosnet, and probably have anything wired into the core of your network. You may also have lucked into a router supplier who has done a better job of mDNS support. So yes it works for you, but only because you’ve hit a sweet spot in a lot of code, much like Mr. Spence’s home no doubt. Others are less fortunate, but that doesn’t mean that the Sonos code works, and that it is their network that is at fault.
I’ve always thought that after the controller App device discovery (SSDP or mDNS) was complete, that the communication thereafter is just unicast? The Group Co-ordinator then does all the work surely - and I can’t see that has changed much as my group playback (and initial mDNS discovery for that matter) is not encountering issues with 10 Sonos Rooms (25 Sonos products in total) - admittedly my product IP addresses are reserved in the routers DHCP reservation table, high up in the subnet - so I don’t expect each players mDNS cache to alter in my case, even if a speaker might ever lose its network connection temporarily - the mesh router I use optimises my connections daily too - during downtime - so that’s usually overnight and often between 4am and 5am.
Just to add too, I’ve not encountered issues, whether I’ve bridged my ISP provided router and used my Mesh WiFi Primary Hub as router, or used the mesh setup in Bridged AP mode and likewise I did see the same robust experience when running my Sonos Products in SonosNet mode linked to either router setup (at least that’s with the products that support SonosNet) with any non-supported SonosNet products running on the 5Ghz WiFi band, which in my case has the same SSID and credentials as the local 2.4Ghz band.
So based on these things I mention collectively, I still see that @BCJ’s reported issue, is more likely network related and I don’t see anything in Andy Pennell’s articles either that takes anything away from that. He admits that his own knowledge of mDNS discovery is limited, but either way looking closer at the LAN/WAN connection here, it is still a good place to begin troubleshooting - and I think we can all agree that the matter is not Sonos App related in any event.
I just don’t get it. Granted, I’m no coder, ‘app developer’ or even a reasonably proficient amateur. And I’m aware that temporal contiguity does not prove causation.
But come on, folks. Tens of thousand of users — likely many times more — had Sonos systems set up in their homes that were working just fine before the watershed date of May 7, 2024. Those same users have had nothing but trouble since. Their networks didn’t change. They didn’t have to spend countless hours delving into the innards of their LAN/WAN, DHCP, mDNS or any other mixed acronym salads to perform basic functions and play their music, using the app that Sonos previously provided.
If the new app is not sufficiently flexible and robust to work properly in varied environments, and to work for all but a small handful of outliers, then sorry, but that’s on the app and the ‘firmware’ — not the customers.
Every other service I use via my home network — streaming video, cable tv networks, music streaming services, whatever — worked before May 7 and continued to work after. Just one thing changed — that damned app and the ‘firmware’ hwhatever that means] on my Sonos speakers.
It’s a home music system. No special skill required and you can find your music and play it — when the ‘app’ and the ‘firmware’ work as intended.
They aren’t working as intended; and they haven’t worked for months now. Period. I’ll be convinced otherwise when I can download an ‘update’ and things return to normal. Until such time, Sonos broke it and it’s up to Sonos to fix it… not me; and not the hordes of Sonos customers who have been nothing but frustrated for months and asked to spend an inordinate amount of time trying to get their Sonos speaker systems to perform as they did before and as they reasonably expect they will again.
If the new app is not sufficiently flexible and robust to work properly in varied environments, and to work for all but a small handful of outliers, then sorry, but that’s on the app and the ‘firmware’ — not the customers.
<...]
They aren’t working as intended; and they haven’t worked for months now. Period. I’ll be convinced otherwise when I can download an ‘update’ and things return to normal. Until such time, Sonos broke it and it’s up to Sonos to fix it… not me.
As usual @chambolle, you capture the zeitgeist of Normal People extremely well! Bravo!
While many users do have issues they can fix themselves, it is dispiriting to see real problems* dismissed with the blinders of “works here, must be something wrong with your setup.”
* Things reported by many users that cannot be fixed by following a set of 1-2-3 instructions
@chambolle,
Just curious, have you spoken to Sonos Support at all about your non-working system and if the answer is ‘yes’ - what was the outcome?
What did the Staff say was the likely cause of the issue you’re seeing?
Also @chambolle you posted a week or two ago saying you were not going to install any further Sonos updates until the point has been reached of ‘reasonable stability’ or words along those lines. So are you still running your setup with an older version of the Sonos App and a newer version of the Sonos firmware, as that might ‘perhaps’ be causing you some additional issues too?
edit: it seems you also avoided the earlier July 22nd Sonos App update too according to your post here:
https://en.community.sonos.com/product-updates/update-on-the-sonos-app-from-patrick-spence-6900501/index2.html?postid=9689#post9689
Yes, Ken, I wasted hours trying to connect with Sonos support. I spent considerable time working with Sonos support. After various tweaks, the upshot was ‘these are known issues’ and ‘that will be addressed in a future update.’ And at one point, someone suggested the entire mess could be caused by a faulty ethernet cable. Far fetched, but I replaced the cable. No dice.
By now, my ‘non-working system’ is working as well as it can given the defects in the app and the firmware. I’ve been able to limp along with the help of a 3rd party app, which at least allows me to locate the music I ‘archived’ in Sonos playlists before May 7. I can live without various buzzers and bells like alarms and sleep timers and voice activation and trueplay and whatnot. I’ve even learned to tolerate annoyances like occasional crashes, slow response to simple commands like volume up or down, and the fact that going from the display of the track playing back to the list of tracks in the queue returns to the top of the queue — pretty inconvenient when the queue is 400 tracks long.
With all that, I’m frankly not all that stressed at this point. I’ll say this, I went freaking ballistic the day I opened the app and all of my music — all of my Sonos playlists —was gone. Disappeared without warning; without explanation; and with no assurance any of it could be retrieved ever again. I thought that was just me — why would I think otherwise? I then noticed the Sonos app would not even allow me to access my music services to play a track at a time, much less start the laborious process of trying to recreate my playlists. Nothing worked, and I had no idea why. That’s when I headed for Sonos support. That’s when I first got a clue this was a firestorm of failure and that Sonos staff was overwhelmed.
Thankfully I now know those playlists have not been lost forever, not yet anyway. But that’s not thanks to Sonos… I had to cast around the ‘community’ for an explanation while Sonos spent weeks pretending everything was perfectly normal and ‘Luddites’ like me must be the problem.
Others still evidently have more debilitating problems with their systems than I do now, or aren’t willing to live without various buzzers and bells Sonos provided before May 7 and that are problematic now. I don’t much care, to be honest. I just want to find, save and play music. Period.
In any event, I am able to play music on my system, so long as I live with the current limitations and try to ignore the annoying bugs. And I am no longer willing to bust my pick trying to chase what is still a moving target while Sonos continues to release update after update in an effort to restore full functionality to its customers.
I await the day Sonos will say — and when I can confirm — that everything works again. I will then download the latest app, update ‘firmware,’ and hopefully can assume it’ll work; and that if it doesn’t, Sonos support can help me fix it without great difficulty. That’s how it’s supposed to work. It hasn’t worked that way since May 7.
And no, I am not going to continue downloading one update after another and thereby risking I will lose the limited functionality I have now. I won’t update ‘firmware’ or the ‘app’ until I am confident both are ready for prime time and not just another experiment. None of the recent updates address my major concerns; and checking into the community posts, I’ve seen many reports that each update has brought new problems. I don’t need new problems. I just need a return to normal, trouble-free operation.
@chambolle,
I understand your frustration and can see most of it in the past has centred around Sonos playlists and queue management/editing - that’s reading back through your posts, but you did mention you were not going to update your App (at least on two occasions) and would not do so until you were happy things were stable.
So I was not sure where you are at the moment, when you mentioned your speakers hadn’t worked for months now. Anyhow I assume now that you mean for your Sonos playlists.
Sonos are aware of that matter and have published this Support link:
https://support.sonos.com/en-us/article/the-new-sonos-app-and-future-feature-updates
I suspect they will be fixed in either September or October - meanwhile you can perhaps continue to access them from the Sonos Desktop Controllers or the 3rd party App you mentioned earlier. There’s not much any of us can do about a missing feature until Sonos restore that functionality.
If you’re having problems with any other areas of the App, then if you’ve not done so already, I suggest you update both your Sonos App and firmware and if problems persist after that, then it maybe best to reproduce the issue(s) seen and then immediately submit a Sonos system diagnostic report from within the Sonos App, note it’s reference and then contact/chat with Sonos Support Staff again via this LINK and see what the Staff can perhaps suggest to help you to resolve the matter.
I’ve always thought that after the controller App device discovery (SSDP or mDNS) was complete, that the communication thereafter is just unicast? The Group Co-ordinator then does all the work surely - and I can’t see that has changed much as my group playback (and initial mDNS discovery for that matter) is not encountering issues with 10 Sonos Rooms (25 Sonos products in total) - admittedly my product IP addresses are reserved in the routers DHCP reservation table, high up in the subnet - so I don’t expect each players mDNS cache to alter in my case, even if a speaker might ever lose its network connection temporarily - the mesh router I use optimises my connections daily too - during downtime - so that’s usually overnight and often between 4am and 5am.
Not completely. SSDP is an announcement based system with regular “heartbeats” so the controller apps have a max age and the devices make announcements to the SSDP multicast addresses at regular intervals. If the controller misses announcements and the max-age hits, then the controller should perform service discovery again.
mDNS is more event based and devices don’t perform regular announcements. When a device starts it goes through a probe phase (to ensure the name it wants isn’t already in use) then an advertisment phase. The device then doesn’t need to advertise itself unless something changes, eg IP address changes, interface goes down and up and it just responds to queries and watches other queries and responses on the mDNS multicast network.
Amongst various timings of when things need to happen the specs also require a randomised window before starting, to prevent things like broadcast storms it a switch is restarted so all devices advertising services stagger their probe/advertisments due to the network interface coming up instead of all hitting the switch in one go.
The static IP addresses are likely to be of little benefit for mDNS. While not hard defined in the specification, the recommended Time To Live setting for records containing host information is 120 seconds. For all other records it is to be set at 75 minutes. Even before a TTL is reached, hosts will update their cache based on other queries and responses they observe if their cache is different and they would expect to answer. It would be an edge case where the cached hostname/IP is reused and the static IP is beneficial for mDNS.
When the controller device last received a host record more than 120 seconds ago it’s cache is already invalid so it needs query for up to date records.
While mDNS shares things familiar from unicast DNS is has it’s own set of requirements and rules to suit it’s purpose for multicast, with no central source of truth and changing devices.
Yes, I’ve seen that September/October is the target date for queue editing and such. I assume that means I will at some point be able to display and open Sonos playlists in the app, without resort to a third party ‘patch’; and that I will be able to add and subtract music from an existing playlist and create new playlists. The fact that might wind up taking five to six months from the initial release date is… let’s just say breathtaking.
I’ve tried using the desktop controller by opening it on my tablet via safari, and it hasn’t worked for me, not sure why. And I’m not about to resort to a laptop just to play some tunes with my morning espresso.
Yes, I’ve seen that September/October is the target date for queue editing and such. I assume that means I will at some point be able to display and open Sonos playlists in the app, without resort to a third party ‘patch’; and that I will be able to add and subtract music from an existing playlist and create new playlists. The fact that might wind up taking five to six months from the initial release date is… let’s just say breathtaking.
I’ve tried using the desktop controller by opening it on my tablet via safari, and it hasn’t worked for me, not sure why. And I’m not about to resort to a laptop just to play some tunes with my morning espresso.
The desktop controllers don’t install/work on tablets - it’s either Windows 10 (or higher) and MacOS 10.12 (or higher) only. Nor do they use a web browser. The controllers are available here:
https://support.sonos.com/en-us/downloads
