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
Achieved 40471 drops and system is constantly dropping, every 5 minutes or so. I suppose there is a threshold value capped to the number of errors an interface can handle following which it drops connections to not cause further damage to the equipment(theory). I suppose Sonos engineering needs to focus on why these packets are dropping across all affected customers. I can certainly tell that the counter resets to 0 following a reboot which explains why a reboot resolves the problem temporarily.
I really like this idea and line of troubleshooting. I’ve started watching for dropped packets while I’m watching content or doing other things (switching inputs, connecting devices, etc.). I will certainly share if I see any patterns emerge.
Edit: so far just a slow accumulation of dropped packets on the arc, nothing on the satellites
Certainly not as technical as the other updates that have been recently posted but I wanted to give an update on my basic testing. As mentioned in a post a few pages back, I had turned of eARC on my system and it was actually quite stable just using ARC. I would only drop the surrounds and subs when using the Xbox. I tried turning eARC back on yesterday and had a drop with just the TV cable box signal within five minutes of just changing the channels around.
Today I got a chance to mess around with the TV some more and tried enabling the Sonos Voice Control on the Arc only. Son of a b&tch if the thing hasn’t been rock solid for the past six hours. I re-enabled eARC and have played music from the app, watched tv from the cable box, played videos on Apple TV that were Atmos and 5.1 and even had the Xbox One work. I’m not ready to declare victory yet but this is by far the most stable my system has been since 14.6 came out. Not a single dropout. I have an LG C1 tv, Nest Mesh wifi and the AT&T wifi box as well which is needed for our upstairs tv that has a wifi box. My sub is a Gen 2 and I use two Play 1s for surrounds. I had tried almost every other fix listed in this thread over the past month or so with so sustainable luck but for some reason the enabling of Sonos Voice Control has brought the most success so far. We’ll see if it holds up but I’m swapping things around like mad that have caused it to break consistently in the past and it’s still hanging in there. I know this is not much comfort to those with the Arc SL and to those who have tried this and didn’t have the same kind of luck. Believe me, I know how you’re feeling. Hoping this holds out and I’m hoping that it may give some insight to the developers that some people are having luck with this simple fix. We shouldn’t HAVE to enable voice control to get our systems to work but, for me, it seems to be a fix that worked.
Update on dropped packets, channels, and voice assistant:
I started watching for dropped packets while my kids were watching 5.1 content on Disney plus on Apple TV.
-no dropped packets for half an hour of watching
-without interrupting content playing, I plugged in and powered on my second Apple TV in the background without switching inputs to it. I’ve mainly experienced dropouts when a second source is connected. With just my main Apple TV, I don’t get dropouts.
-experienced 4 dropped packets (on Arc only, none on HT satellites) during power on. Then nothing for a bit. Experienced 16 dropped packets approximately coinciding with second Apple TV going to sleep
-powered on second Apple TV again and let it go to sleep on its own. No additional dropped packets.
-bounced around content and eventually Netflix Auto play trailers and caused a dropout. No additional packets dropped.
I had enabled Sonos voice assistant last week and finally got around to doing a full power cycle of all devices 2 or 3 days ago. This was my first dropout since.
I started at 1034 dropped packets on Arc, 0 on HT satellites. I ended at 1058 dropped packets on Arc, 0 on satellites.
Arc started and ended on “operating on channel 2437”. No change before and after dropout. HT Satellites started and ended on “operating on channel 5240”. No change before and after dropout.
I don’t feel I can add much weight to any of the recent theories unfortunately - voice assistant, dropped packets, or operating on channel.
The one constant for me that has been reinforced again is I don’t get dropouts with only one source connected. Shortly after connecting a second source, I’m likely to get a dropout.
+6
just had it happen again. I’m convinced this is not network related
just had it happen again. I’m convinced this is not network related
Me too
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
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
Yes, both unmanaged ‘dumb’ TP-LINK switches.
+6
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
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).
The above two items should enable us to triangulate a little on what
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)
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.
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.
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).
The above two items should enable us to triangulate a little on what
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)
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.
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!
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!
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.
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!
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
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!
Right. That’s makes a lot of sense since the speakers stay connected in the App (which is on the home network). You are still able to control the volume/mute buttons on the speakers even though they may have dropped out of this AD-Hoc network created by the Arc for the Audio channels? I find it amazing that Sonos haven’t investigated this for themselves and been able to reproduce this issue. I wonder if there is a certain revision or serial number range that is effected by the 14.6 firmware.
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
Thanks
However, the essence is that we want to assess (in your case) two things.
Right. That’s makes a lot of sense since the speakers stay connected in the App (which is on the home network). You are still able to control the volume/mute buttons on the speakers even though they may have dropped out of this AD-Hoc network created by the Arc for the Audio channels? I find it amazing that Sonos haven’t investigated this for themselves and been able to reproduce this issue. I wonder if there is a certain revision or serial number range that is effected by the 14.6 firmware.
Correct - something that Peter and I stumbled across last night. (Well, during his day for him as I am in the UK!). This is why we can see and control the ARC (SonosNet/Wi-Fi), but a possible reason why the surrounds/subs ( Ad-Hoc 5Ghz network) are not working.
If we can understand whether a move in this channel always correlates to a sound drop then we are one small step forward. If not, then we know we have (at least) another problem!
I wonder if there is a certain revision or serial number range that is effected by the 14.6 firmware.
And yes, I have had in the back of my mind whether this could be a factor. Some software components or even hardware components in this systems can change mid production. So this is a possible cause - but lets hope it is not the cause. As convincing a vendor that this is the case and asking for replacements is not going to be easy. However, I will say that one person was sent a new ARC as a replacement and still had the issue. So who knows?!
In terms of the packet drop scenario, here is a screenshot below (of the ARC metrics) after a reboot this morning and leaving a movie running in the background.
Although I am not sure what device br0 is, its the one with the most TX/RX during playing the movie and constantly incremented - which you would expect and means it the most likely communicator during HT operation.
Strangely, the TX (transmit) looks to have no drops in the 1.1GB of data that was sent. However, the RX (receive) has 29% packet drop but only 44MB of data sent.
Again, I don't know if this is normal or what the RX is used for - presumably some heartbeat or sync comms between the units? But this is what I am seeing - whether its is part of this issue or not I do not know.
just had it happen again. I’m convinced this is not network related
I have tried hard coding WiFi channel to use a specific channel for 2.4 and 5Ghz in the past but it didn’t help. This is definitely software related, I see all grays in network matrix even when the system works fine.
In terms of the packet drop scenario, here is a screenshot below (of the ARC metrics) after a reboot this morning and leaving a movie running in the background.
Although I am not sure what device br0 is, its the one with the most TX/RX during playing the movie and constantly incremented - which you would expect and means it the most likely communicator during HT operation.
Strangely, the TX (transmit) looks to have no drops in the 1.1GB of data that was sent. However, the RX (receive) has 29% packet drop but only 44MB of data sent.
Again, I don't know if this is normal or what the RX is used for - presumably some heartbeat or sync comms between the units? But this is what I am seeing - whether its is part of this issue or not I do not know.
Bit if background regarding TX and Rx — Tx is transmission, Rx is receiving (coming from Cisco networking 😊). Both parameters apply to interface, I suppose br0 is one of the interfaces that is talking to other satellites. So effectively, transmitting and receiving data. Now since we are analysing data from Arc, I would assume that packets received by arc are getting dropped. Not sure what threshold is there, but usually once a threshold is met (in terms of errors), Audio drops are seen. My experience is that the dropped packets increase rapidly when changing formats.
Certainly not as technical as the other updates that have been recently posted but I wanted to give an update on my basic testing. As mentioned in a post a few pages back, I had turned of eARC on my system and it was actually quite stable just using ARC. I would only drop the surrounds and subs when using the Xbox. I tried turning eARC back on yesterday and had a drop with just the TV cable box signal within five minutes of just changing the channels around.
Today I got a chance to mess around with the TV some more and tried enabling the Sonos Voice Control on the Arc only. Son of a b&tch if the thing hasn’t been rock solid for the past six hours. I re-enabled eARC and have played music from the app, watched tv from the cable box, played videos on Apple TV that were Atmos and 5.1 and even had the Xbox One work. I’m not ready to declare victory yet but this is by far the most stable my system has been since 14.6 came out. Not a single dropout. I have an LG C1 tv, Nest Mesh wifi and the AT&T wifi box as well which is needed for our upstairs tv that has a wifi box. My sub is a Gen 2 and I use two Play 1s for surrounds. I had tried almost every other fix listed in this thread over the past month or so with so sustainable luck but for some reason the enabling of Sonos Voice Control has brought the most success so far. We’ll see if it holds up but I’m swapping things around like mad that have caused it to break consistently in the past and it’s still hanging in there. I know this is not much comfort to those with the Arc SL and to those who have tried this and didn’t have the same kind of luck. Believe me, I know how you’re feeling. Hoping this holds out and I’m hoping that it may give some insight to the developers that some people are having luck with this simple fix. We shouldn’t HAVE to enable voice control to get our systems to work but, for me, it seems to be a fix that worked.
In terms of the packet drop scenario, here is a screenshot below (of the ARC metrics) after a reboot this morning and leaving a movie running in the background.
Although I am not sure what device br0 is, its the one with the most TX/RX during playing the movie and constantly incremented - which you would expect and means it the most likely communicator during HT operation.
Strangely, the TX (transmit) looks to have no drops in the 1.1GB of data that was sent. However, the RX (receive) has 29% packet drop but only 44MB of data sent.
Again, I don't know if this is normal or what the RX is used for - presumably some heartbeat or sync comms between the units? But this is what I am seeing - whether its is part of this issue or not I do not know.
👆👆👆@Sonos, hire this guy or at least give him a cruise 👆👆👆
Couple of observations:
Something to test:
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
