Skip to main content
Contributor I
April 23, 2022

Lost surround and sub ( after update ?)

  • April 23, 2022
  • 1604 replies
  • 81294 views

Hi 

I don’t know if my issue is related to the 14.6 update but I noticed today that I had no sound from my surround (play 3) and my sub (Gen 2), only the Arc is working They are still present in the app under the my System view but now sound which every sources

When I reboot each of them, the sound comes back temporary, but when I switch to another source or audio format, thé Sound disappears again. Tried several times, same behavior

Thanks for your help

 

This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

1604 replies

Lyricist III
June 12, 2022

Part of the update process is the speakers rebooting, which causes them to ask for new IP addresses from your router. If the router is in a “bad state” and handing out duplicate IP addresses, then your speakers will be compromised due to that. That’s just one scenario. There’s also outside influences that affect wifi, as suggested in the wifi interference FAQ. 

There’s no “it’s just one thing” fix to some of these issues, from what I can tell. There’s a wide variety of reasons why a particular symptom may be displayed. Sure, it’s easy to blame a software release, but if Sonos has, as they have, that they’re unable to duplicate that issue, it’s up to us, as users to give them examples, by submitting diagnostics and telling them about them.

As some may not know, just submitting a diagnostic does no good, it’s explained in Diagnostics - How do they work? thread that you must tell Sonos the number of the diagnostic, and why you’ve submitted it, so they know both to look, and what to look for. Many people in this thread have done that already, I honestly don’t know if everyone has or not.

But if there’s a real issue here, I’d have thought that the Sonos team could have recreated it based on the information they’ve been handed. The fact that they haven’t is somewhat telling, although it’s certainly possible they just don’t have enough information yet. I don’t know, one way or another, but can certainly express that this issue has not appeared on either of my Arcs, both of which have Subs and Surround speakers set up. 

I would be curious to know what your equipment is in each Arc group and whether you have Voice Control enabled. Info from people NOT having this issue is as helpful as those who do. If you haven’t already, please consider filling out the spreadsheet with your system info.

https://docs.google.com/spreadsheets/d/1Q6Iq2xXXZ--RmnsGnbZhujxJj1BcwJlvqSzj5iZXz2U/edit?usp=sharing

With most of the normal Sonos issues calling in and going through their troubleshooting usually fixes it long term.  I don’t think that’s happening with this issue.  As far as I know even those who have made it to Level 3 Engineering are still stuck in the process waiting for a resolution.  I certainly don’t envy Sonos trying to troubleshoot a problem that they can’t reproduce.  Those are always the worst.

I finally got around to adding my 2 systems to the doc. thanks for setting this up. 

I still haven’t had any issues since setting up Sonos voice control on my living room system

This spreadsheet was actually setup by @willhowe. I keep hoping the answer is going to magically appear in there, but it just seems to reinforce how maddeningly elusive this issue is.

Lyricist III
June 12, 2022

Hi everyone.

Yup, just found this thread! I’ve been going mad with my Sub and Surrounds “ghosting” after I launch the Apple TV app!

Like everyone on here, I’ve tried everything from power cycling my Arc/Sub/Surrounds as well as my eero pro router. 

Definitely not my router. (not network related)

 

I’ve managed to figure out what “action” causes my Sub and Surrounds to “disconnect”. 

 

For me, it’s every time I launch the Apple TV app. (100%)

 

I’m not sure if this is a SONOS issue, or a tvOS issue. For now at least I can add them back successfully. Just annoying when I notice them getting disconnected. Hopefully either side is aware, and a fix is on the way!

 

Sonos Arc, 2nd Gen Sub, 2 Play:1s, LG C1 2020 65”, Eero Pro router

Enthusiast II
June 12, 2022

@Brad Porter do you have any network switches in your network? 

Yes, both unmanaged ‘dumb’ TP-LINK switches. 

peterbault
Enthusiast II
June 12, 2022

@Brad Porter do you have any network switches in your network? 

Yes, both unmanaged ‘dumb’ TP-LINK switches. 

Exact same here. 🤔 I’m exploring a hunch. I just removed all my switches from my network and will see if anything changes 

Enthusiast II
June 12, 2022

just had it happen again. I’m convinced this is not network related 

Me too

So this is where I am thinking about this.

Sorry its a little long, but please read as I want to make sure my thinking and testing approach is reasonable. 

I am closer to thinking (although not ruling out 100%) this is possibly not a network issue in terms of our home mesh/router network, but there is something still to explore in the ad-hoc network that Sonos sets up and maintains as part of Home Theatre connectivity. Logic would suggest that global failure of routers/home networks or the global introduction of interference is unlikely to occur simultaneously in April. Probability is that this is change related somewhere in the eco-system and having a direct or indirect trigger of the issue. 

I think we need to do a few things if we are going to understand this more. (Happy to get some feedback to make sure we all agree on the approach before we head off down a path). 

  1. Firstly, 2 people, thus far, have confirmed that the Operating Channel has changed at some point during a sound drop out. I think we need to have more people who are affected with the issue monitor their Operating Channel and ARC packet loss when the system is working, and then check if the Operating Channel has changed as soon as sounds has dropped or impacted. This will start to focus in on whether HT ad-hoc network channel changes are related (or at least present) during the issue and if packet loss features. 
  2. Secondly, we need to have people who are not effected by the sound issue, monitor their Operating Channel and packet loss and see if they experience changes of the frequency. i.e. does it remain solid on one channel, or does it change BUT still work despite that frequency change. 
  3. Thirdly, we should record the ad-hoc channel it was operating on + ARC Packet Loss when it was working, and then when it was not working (or changed and remains working) and post here for some visibility and analysis. i.e. I note that the channel myself and Peter got changed to was a DFS channel. Might be nothing, but data is always helpful to rule in or out. 

The above two items should enable us to triangulate a little on what @Ken_Griffiths originally advised we should monitor and get to understand if this is part of the problem or not. Both him and @ratty seems to have a good understanding of the Sonos Network side so it would be great to get their feedback and experience based on our data.

If we can prove correlation between the ad-hoc HT channel movement and the sound issue, but we are not experiencing any other networking issues on our broader network, then we have something to ask Sonos about in terms of the ad-hoc channel behaviour and why this could be occurring. We may also find a correlation between high packet drops on the ARC, and then a channel change. 

Stuff to think about (Brads mad ramblings)

  • There are users on this forum that have been rock solid for months.  Some have had the issue (like Peter) on their rock-solid systems after nearly two months. So it is plausible that this can occur after some time, or maybe never at all. Therefore, I think it's the ‘trigger point’ that we really don't understand. yet. i.e. why some people get it in 5 mins, why some people are running for hours/days/month before the issue and why some people have not had the issue. Everything we need to do is better understand that trigger point as much as possible - and that does require quite a bit of effort and discipline! 
  • In terms of the trigger point, I am not convinced its just Apple TV. Some people don't use Apple TV and have experienced the issue. It could be Apple TV is used more and exasperates the issue more, but we must remember that Apple TV does not correlate to all issues of sound drop-outs.
  • In terms of packet loss, I think we need to compare this with people who having a working and solid HT setup. I suspect that packet loss will be there as well but we need that comparison to rule in/out whether it's an issue. I do agree that drops are not good, but drops should more than likely cause choppy sound rather than no sound at all. Unless packet loss is a trigger for Sonos to change the ad-hoc 5Ghz channel and thus the problem. We should also remember that some people have moved from Standard Wi-Fi, to Wired and to fully Ethernet connected on all speakers and still get the problem. That does not mean its NOT a network issue, as whether wired or wireless, there is still networking protocols and transit to consider within the Sonos eco-system. 

Where is Brads head right now?

My personal thoughts at this stage (and I probably should not solution-ise, but just for transparency) is that the issue triggers at random times and is not consistent. i.e. its not always “move from Disney to Netflix and the problem is 100% triggered at that point’. So we are dealing with a level of randomness before the issue occurs. Moving HT ad-hoc channels due to interference, packet loss triggering a channel change etc are all possible trigger points which are likely to occur at random times rather than be consistent. i.e. a packet loss trigger to move channels would occur based on the amount of data pushed through the ARC before it decides to move, and interference is random by definition and based on what is occurring in the network at that time.

So my head is a little fuzzy to be honest. But when I think about randomness I do think about things like packet loss and network changes or interference as they are not the same as a specific bug which is triggered when the code goes through a routine and hits that line of code with a bug - that would be pretty consistent to replicate in my mind. 

What does everyone think? Its a long post, but it might be good to digest my thoughts and think about whether we need to adopt or change the approach. To be honest, I am all ears for any suggestions and thoughts. 

 

Lyricist III
June 12, 2022

just had it happen again. I’m convinced this is not network related 

Everybody here has a different setup, varying TVs, Arcs or Beams, Gen 2 or 3 subs, various models of surround speakers and a vastly wide array of network setups.

 

The one thing everyone has in common with this issue is that it started with the 14.6 update. It’s good to see people in this thread doing Sonos job for them. 

Enthusiast II
June 12, 2022

just had it happen again. I’m convinced this is not network related 

Me too

So this is where I am thinking about this.

Sorry its a little long, but please read as I want to make sure my thinking and testing approach is reasonable. 

I am closer to thinking (although not ruling out 100%) this is possibly not a network issue in terms of our home mesh/router network, but there is something still to explore in the ad-hoc network that Sonos sets up and maintains as part of Home Theatre connectivity. Logic would suggest that global failure of routers/home networks or the global introduction of interference is unlikely to occur simultaneously in April. Probability is that this is change related somewhere in the eco-system and having a direct or indirect trigger of the issue. 

I think we need to do a few things if we are going to understand this more. (Happy to get some feedback to make sure we all agree on the approach before we head off down a path). 

  1. Firstly, 2 people, thus far, have confirmed that the Operating Channel has changed at some point during a sound drop out. I think we need to have more people who are affected with the issue monitor their Operating Channel and ARC packet loss when the system is working, and then check if the Operating Channel has changed as soon as sounds has dropped or impacted. This will start to focus in on whether HT ad-hoc network channel changes are related (or at least present) during the issue and if packet loss features. 
  2. Secondly, we need to have people who are not effected by the sound issue, monitor their Operating Channel and packet loss and see if they experience changes of the frequency. i.e. does it remain solid on one channel, or does it change BUT still work despite that frequency change. 
  3. Thirdly, we should record the ad-hoc channel it was operating on + ARC Packet Loss when it was working, and then when it was not working (or changed and remains working) and post here for some visibility and analysis. i.e. I note that the channel myself and Peter got changed to was a DFS channel. Might be nothing, but data is always helpful to rule in or out. 

The above two items should enable us to triangulate a little on what @Ken_Griffiths originally advised we should monitor and get to understand if this is part of the problem or not. Both him and @ratty seems to have a good understanding of the Sonos Network side so it would be great to get their feedback and experience based on our data.

If we can prove correlation between the ad-hoc HT channel movement and the sound issue, but we are not experiencing any other networking issues on our broader network, then we have something to ask Sonos about in terms of the ad-hoc channel behaviour and why this could be occurring. We may also find a correlation between high packet drops on the ARC, and then a channel change. 

Stuff to think about (Brads mad ramblings)

  • There are users on this forum that have been rock solid for months.  Some have had the issue (like Peter) on their rock-solid systems after nearly two months. So it is plausible that this can occur after some time, or maybe never at all. Therefore, I think it's the ‘trigger point’ that we really don't understand. yet. i.e. why some people get it in 5 mins, why some people are running for hours/days/month before the issue and why some people have not had the issue. Everything we need to do is better understand that trigger point as much as possible - and that does require quite a bit of effort and discipline! 
  • In terms of the trigger point, I am not convinced its just Apple TV. Some people don't use Apple TV and have experienced the issue. It could be Apple TV is used more and exasperates the issue more, but we must remember that Apple TV does not correlate to all issues of sound drop-outs.
  • In terms of packet loss, I think we need to compare this with people who having a working and solid HT setup. I suspect that packet loss will be there as well but we need that comparison to rule in/out whether it's an issue. I do agree that drops are not good, but drops should more than likely cause choppy sound rather than no sound at all. Unless packet loss is a trigger for Sonos to change the ad-hoc 5Ghz channel and thus the problem. We should also remember that some people have moved from Standard Wi-Fi, to Wired and to fully Ethernet connected on all speakers and still get the problem. That does not mean its NOT a network issue, as whether wired or wireless, there is still networking protocols and transit to consider within the Sonos eco-system. 

Where is Brads head right now?

My personal thoughts at this stage (and I probably should not solution-ise, but just for transparency) is that the issue triggers at random times and is not consistent. i.e. its not always “move from Disney to Netflix and the problem is 100% triggered at that point’. So we are dealing with a level of randomness before the issue occurs. Moving HT ad-hoc channels due to interference, packet loss triggering a channel change etc are all possible trigger points which are likely to occur at random times rather than be consistent. i.e. a packet loss trigger to move channels would occur based on the amount of data pushed through the ARC before it decides to move, and interference is random by definition and based on what is occurring in the network at that time.

So my head is a little fuzzy to be honest. But when I think about randomness I do think about things like packet loss and network changes or interference as they are not the same as a specific bug which is triggered when the code goes through a routine and hits that line of code with a bug - that would be pretty consistent to replicate in my mind. 

What does everyone think? Its a long post, but it might be good to digest my thoughts and think about whether we need to adopt or change the approach. To be honest, I am all ears for any suggestions and thoughts. 

 

How can I check the channel thing? I don’t have the problem anymore so maybe it’ll help with something.

Enthusiast II
June 12, 2022

Everybody here has a different setup, varying TVs, Arcs or Beams, Gen 2 or 3 subs, various models of surround speakers and a vastly wide array of network setups.

The one thing everyone has in common with this issue is that it started with the 14.6 update. I really commend everybody here for their investigation into network and interference issues, however I really don’t think it’s the problem, if it is the problem, why is my network dropping out when I change input? Or when I pause and unpause a movie? This is when the issue occurs for me.

I don't disagree. However, I think everyone is thinking of a network problem as something inherently wrong is their home network setup - which is unlikely due to the problem occurring for many around a time in April.

However, there is the HT Ad-Hoc Network which we need to consider which is setup by the ARC. It is possible that a trigger occurs which disrupts this ad-hoc channel in some way- which is not network problem in our home setup but something within the Sonos eco-system. 

As mentioned in my long (and boring) post above, we still don't understand the trigger. Which is the proverbial needle in the haystack in all this!

Enthusiast II
June 12, 2022

How can I check the channel thing? I don’t have the problem anymore so maybe it’ll help with something.

That's a good point! 

  • Go to http://XXX.XXX.XXX.XXX:1400/support/review (where XXX is your IP of your Rear Speaker or Sub).
  • A bunch of links will appear on the web page.
  • Click TV Room (RR) - which is TV Room Right Rear (although you could use Left Rear or Sub). 
  • Once that menu expands, click /proc/ath_rincon/status link.
  • In here you will see a load of data, but you want to focus on Operating on channel value - which is the frequency. Example screen shot below where mine is currently on 5220 whilst playing a movie. 
  • Compare this to the TV Room (LF,RF) value. This time look for the HT Channel value.
  • The value of Operating on channel in the rears/subs should match the HT Channel in the ARC (which is the TV Room (LF,RF))

NOTE: You must be playing content/movies before you capture the frequency. It goes back to a 2.4Ghz frequency when the system is idle. 

Let me know if that works for you.

 

Enthusiast II
June 12, 2022

How can I check the channel thing? I don’t have the problem anymore so maybe it’ll help with something.

That's a good point! 

  • Go to http://XXX.XXX.XXX.XXX:1400/support/review (where XXX is your IP of your ARC.
  • A bunch of links will appear on the web page.
  • Click TV Room (LF,RF) (RINCON_XXXXXXXXXX) 
  • Once that menu expands, click /proc/ath_rincon/status link.
  • In here you will see a load of data, but you want to focus on Operating on channel value.

NOTE: You must be playing content/movies before you capture the channel. It goes back to a 2.4Ghz frequency when the system is idle. 

Let me know if that works for you.

This is while playing an Atmos movie:Mode: INFRA (station)Operating on channel 2462Home channel is 2462HT Channel is 5200RF Chains: RX:4 TX:4RF Chainmask: RX:0x0FTX:0x0FMax Spatial Streams: RX:4 TX:4