High dropped packet rate on br0 interface

Hi @Corry P 

Created a new thread so as not to takeover @sigh wonky network…

My immediate question is why would the Play:3 be pegged at 100%? All it does pretty much is play local Apple Lossless CD quality (16-bit, 44.1KHz) files from a NAS, which is all it’s ever done. It doesn’t generally have to deal with higher quality streams. Beyond that it’ll get grouped with one or two more speakers. I don’t recall the grouping order but to be fair I’m not sure you should have to. Much depends on where you start listening so you get the music you wanted. 

I don’t understand why such a light load use case would be chewing that much CPU? 

Also, what is using all the memory? The local library that would be indexed on the speakers is only approx 1000 CDs and about 13,000 songs which is a long way hopefully from metadata limits… or is it? Again, I can’t imagine the Play:3 should be that tight on memory? I have  quite a few compilation albums so is the broken indexing that turns one album into 50 responsible for a huge increase in metadata memory use? 

Are DEAUTHS something the Linksys Velop nodes force on the Sonos nodes? I have them set to static IP’s through DHCP reservation, but do notice they seem to move around quite a bit on the WiFi, with between nodes and bands. Is that client/band steering in action? The Velops are not that new, but I don’t get internet dropouts on phone, iPad etc. All the Sonos products support 5GHz but don’t stay on it 🤔

Sonosnet is not the answer for me. I’m trying to move away from that as I don’t want two mesh networks and there are lots of other networks nearby. (Likewise I have to regularly check that the Sky Q boxes haven’t re-enabled their mesh WiFi after any updates and disable it again!) The Move also doesn’t support it, so I don’t see it as a long term answer. When I did have it (I’d upgraded a Connect to a Port) and hadn’t realised doing that had created it, I had the horrible lagginess everywhere. Getting rid of it has improved the current app behaviour in terms of responsiveness. 

I have been using Sonos less, and using my hifi streamer more recently as the lack of queue edit function in Sonos is a real pain for me, and the hifi streamer still does that. 

When I group is when I often get the audio dropouts, along with the Move occasionally doing weird things which I have seen others report. So something is not quite right, and lots of dropped packets in the number I’m seeing doesn’t to me indicate health, and neither do the things you mention from the diagnostics, so I would like to try and get to the bottom of it in time for a fanfare to mark the return of proper queue editing 📣

It wasn’t that long ago that everything was rebooted, including the Velops, and again, constant reboots aren’t an answer for me. 

Thanks for your help 👍

I wouldn’t worry about the dropped packets in bridge interface, they maybe intentionally dropped.

I would focus more on the deauths that Corry mentions.

The WiFi client will always decide which AP to connect to, but the AP may have some logic, possibly propriety, to ‘guide’ to what the AP thinks is a better channel/AP. eg some will try to balance between 2.4GHz and 5GHz channels, or balance number of clients on an AP, or try to move clients to 5GHz. This is conflicting with what the client (Sonos device) thinks is best.

I don’t know the Velop software, but I would disable DFS, lock down the channels (don’t have auto) after an environment scan. You have Apple device, use the free Apple Airport utility to do and environment scan, you can use if without AIrports to scan. 

I use 20MHz for 2.4GHz and 40MHz for 5GHz channel width.

Try to make the static devices, eg non roaming Sonos ‘sticky’ to the best AP.

In terms of memory, maybe remove any Music services you are no longer using from your Sonos system?

You definitely don’t need SonosNet if you you have a reliable/stable WiFi.

Sky WiFi mesh and another mesh will also conflict.

They may be intentionally dropped, but you’d expect an even spread across Sonos devices, the Play:3 is dropping hardly any. That makes no sense… unless it’s so busy just ‘breathing’ that the other devices are dropping packets waiting for the Play:3, either way to my mind it shows something is amiss. 

I do have the WiFi frequencies fixed, and use a Mac app called WiFi explorer to periodically monitor WiFi channels and see if other nearby routers have piled in on mine! 

I don’t have many music services, just Amazon, Qobuz & Spotify.

However the local library issue could well have ballooned the local indexes quite substantially. I have 77 albums in the compilations folder, and a quick find into a line count shows 2255 tracks, which is an average of 30 tracks per album… given that the bug now creates one new album per different combination of artist vs. album artist, which is almost one album for every track as I don’t include greatest hits in compilations, and within each album you appear to then have all the tracks, that means you end up with 77x30x30 potential tracks which is 69300 tracks…. 😱 Now I’m guessing I have less than that, but with around 11,000 other genuine tracks on top of the broken compilation entries??? When I go into Various Artists on the desktop controller the album list is huge, and when I randomly go into any of them, each appears to have most of the tracks for that compilation listed albeit in a weird order. 

I don’t know if the internal Sonos OS has some concept of paging, or garbage collection and is that causing the Play:3 to peg its CPU at 100% as it can no longer fit the index? All the other speakers have more memory than a Play:3 so may be coping better with the abnormal index? 

I can’t easily remove the compilations as Sonos is sharing with my Apple Music app on a Mac as I use that to allow me to have songs downloaded to my phone for use in the car, so would have to remove the compilations from Apple Music and then I’d lose the ability to sync my phone until sorted… so wouldn’t be able to change music without losing a lot of songs… 

It’s all a bit of a mess frankly. 

Focus on this:

If the speakers are constantly reconnecting to different AP and/or channels, this will cause an increase in CPU load.

Not pegged at 100% CPU though. That’s rather extreme… That would imply it’s constantly changing WiFi AP … and never settling at all. 

Hi @Ian_S 

It may simply be that a thread has stalled. Hopefully, a quick reboot will resolve.

The internal flash storage can degrade over time, with more and more bad blocks taking up available space. It could also be the stalled thread just eating up spare memory.

You can see the report here:

The response codes are as follows:

• r2 - Previous authentication no longer valid - Client has associated but is not authorised.
• r3 - Deauthenticated because sending STA is leaving (or has left) IBSS or ESS - The access point went offline, deauthenticating the client.
• r6 - Class 2 frame received from nonauthenticated STA - Client attempted to transfer data before it was authenticated.
• r8 - Disassociated because sending STA is leaving (or has left) BSS - Operating System moved the client to another access point using non-aggressive load balancing.
• r999 - Typically “No Reason Code” / Unknown State

I know what none of this means.

The BADCRED column is a count of how many times the speakers were told that they used the wrong credentials. This is in the uptime of the speakers, which is near a month, so these errors could have occurred at any point in that month.

I assume the speakers are moving from AP to AP as a result of them being told that they are not allowed to connect - speakers will always attempt a connection to the AP that they last had a successful connection with, so if they are jumping around, it is because they have been given no choice. This is the reason I suggested SonosNet.

Fair enough - we typically use it as an equal but different alternative - if someone is having issue on WiFi, we suggest SonosNet, and if someone has issues on SonosNet, we’ll suggest WiFi.

We’re working on that - hopefully won’t be much longer now.

I agree - you shouldn't have to. But, if it does help, it typically indicates an issue with the configuration of the router.

You’re welcome - I hope you do find it helpful.

@Corry P Before I reboot the Play:3, are you saying the CPU is currently pegged at 100% all the time? Even when it’s not playing any music, or just when it’s playing something? If the latter, are you able to see what the CPU is when ‘idle’? Also what process name is consuming all the CPU? 

And yes, the info you are able to get out of the diagnostics and share is extremely helpful, or at least I find it helpful! 

Hi @Ian_S 

I don’t think it was at 100% all of the time - we just get an entry in one log when it’s at 97% or more, and I see a lot of those. But, there is a period of 24 hours before the diagnostic when it was only reported once. There was another period where it was reported every 10 seconds or so for half an hour and nothing else was reported in that period. The name of the process is not reported, as far as I know.

If I see this, I ask for a reboot - I don’t tend to go too far into the whys of it, I‘m afraid.

Had avoided posting here as the support case is in theory still active, but have heard nothing back. Kitchen dropped out again when grouping, it wasn’t the initial zone, I added kitchen to something else. Submitted a diagnostic again…. 

Hi @Ian_S 

Sorry to hear that!

I went to look up your case just now to see if I could see what the delay was, but you don’t appear to have an open case - perhaps you used a different email? If you DM me the case number, I can take a look for you.