Skip to main content

After deciding to sacrifice my unused Sonos speakers to the upgrade gods, it didn't take long to run into an issue.

Playing back music, I had repeatable on demand issues

  • If a group contained 4 or more devices, there is a delay of up to 12 seconds or music dropping in and out during the first 12 seconds on all devices except the group controller when starting music or changing tracks. By devices that includes a sub and/or stereo pairs, not 4 sonos rooms.
  • Changing group members in the app gets slow after the above and playing music. Track progress starts getting jumpy, cloud api calls take longer.

I have spent some time investigating and think I know what is causing my speakers to have issues while grouped, which also introduces random app behaviour, cannot contact messages, slow responding. More often than not, once the controller gets into a state it doesn't recover and requires fully closing and reopening to return to normal.

Why I didn’t instantly assuming it was my network

  • For the past 3 years my Sonos has been completely trouble free, unless I was fiddling in my network settings and broke something myself. I have visibility on data about most parts of my network, so it’s usually obvious when something is wonky

Changes of note during past year

  • I no longer have my Sonos amps, port or one of the subs - the lack of port may have contributed
  • I have added some Yamaha gear which uses multicast, including from my HT AVR → Sub, so it is obvious when multicast is playing up because the avr and sub separate.
  • I replaced my noisy all singing all dancing enterprise managed POE switches for more suitable, fanless managed SMB switches about a year ago. Far less settings to fiddle and break things with 😊
  • Following the upgrade was the first time I added a wifi network for a while. I’ve been on SonosNet for over a year. Maybe time to blame the missing port again 😁

@sigh It is interesting with your test case as I’m assuming it was a dedicated network for testing just Sonos, and there shouldn’t have been anything else multi-casting … I’m equally confused by why in my network the Play:3 speaker appears immune to the large number of logical dropped packets that all my other speakers seem to get… 

Yeah, its a strange one.

I moved all the Sonos devices behind a router with a switch attached so I could mirror the SonosNet port.

Router is openwrt and has the most basic firewall I could do. masquarade lan to wan and allow all outbound, don’t allow inbound from wan.

Yesterday I was collecting family so got my hands on a mini pc with win 11 on it. Went even more basic with the network and disabled wifi on the router. The only common device between my home network and this one is the iPad, so removed it from the equation. Installed the desktop app on the mini pc and left the windows interface as public to stop it looking for things.

Only powered on the 2.1 setup with gen1 bookshelfs and sub mini and the 2nd gen bookshelf as an additional group member. The other three speakers were left off and the group coordinator was used to wire into the switch as Corry suggested.

The only devices and potential sources of multicast were the now ethernet only router, the mini pc, the gig switch and the sonos devices. The laptop running capture is on a mirror of the Sonos switch port, so doesn’t send anything into the switch.

Only tried with Qobuz hires, but it still the same behaviour of group coordinator plays fine while the group members drop out and then recover. The difference last night was instead of seeing igmp v2 group leaves like Saturday, the speakers were issuing igmp v3 group joins on every track change when they dropped out. 🤷 regular as clockwork.

 

Last test before calling it a night was to plug the mini pc and the sonos group controller into the router ethernet ports and disconnect the switch. No way of capturing traffic, but can’t really make the network any smaller than that. Still the same behaviour 😂​​​​​​


`Curiouser and curiouser!' cried Alice

The screenshot with the times was very useful for narrowing down the capture file @Corry P 

Doesn’t help shed any light for the source though. 🙄

During that period, the playback issue was that while there might be the occasional few seconds of sound, it was mostly silent with the track being played moving to the next track in the album after ~20-30 seconds.

The source was the nas and in the capture for the time range shows the group coordinator opening and the file, pulling data and then closing it before switching to the next one.

Where it gets odd is either the capture is missing data or the source didn’t come in via the switch port.

For the entire time range out of 352,117 captured most were tcp. smb, a little tls.

Filtering out tcp and anything without a sonos mac as a destination left 3,268 for the entire time range.

Filtering out tcp and sonos as the source or destination mac, which should show any other sources left 132 packets, so either the port mirror and capture is missing a lot of data, it isn’t multicast/broadcast or it didn’t come through the switch port from the router, switch or ipad which were the other things on the network. 🤔

Or I’ve messed up my filters, which is always possible, but nothing stood out going through the minute by minute times 😂

Would have been nice to be able to go “aha, gotcha”

No TCP or Sonos mac destination
No TCP, No Sonos mac source or dest
No TCP, No Sonos mac source or dest

 


Reply