Skip to main content

With both Apple TV and Spotify, while playing music, Sonos will frequently stop playing a track in the middle and skip immediately to the next track in the queue. I’m a long time Sonos user and this behavior started maybe 6 months or so ago. I’m using S2 and the network matrix has only green squares, except for a couple of zones that are white and don’t show any OFDM ANI or noise floor info. They do have green squares in the body of the matrix though. Any ideas?

Try some of the troubleshooting tips in this article:

https://support.sonos.com/s/article/305?language=en_US


If there is a data starvation issue, players will move on to the next track.

It is unfortunate that some of the diagnostic information is hidden from us. The newer units do not populate the left column of the Network Matrix.

There is a little raw data available in /proc/ath_rincon/status and /sbin/ifconfig for each Room. None of this is defined beyond what you see and can deduce. It would be interesting to watch for changes in error counts. If error counts move faster for one unit compared to the others, this is probably a hint. A problem is you don’t have very good control over the logging interval. Most of the data, but not all, is reset between page refreshes.

A phone/pad WiFi scanner App can be useful tracking down sources of interference, such as unfortunate WiFi channel assignments of nearby clients and access points. Android is much more useful than iOS for this sort of App.


PING each player and look for dropped packets and PING time.


I looked through the suggestions in that link and I don’t think any of them are a problem. Noise floors in the network matrix are all around -100 to -113 which seems good. When I stream FLAC files from my Nas over Sonos there is no skipping and we are able to stream 4K videos without any issues. It’s only Sonos streaming music that has a problem.


PING each player and look for dropped packets and PING time.

I gave this a try for a couple zones and found return times in the range of 2 - 20 ms. There were no dropped packets for the short time I let it run. However, I think the fact that music plays fine from the Nas suggests that it’s not a wireless interference problem. 

 

There is a little raw data available in /proc/ath_rincon/status and /sbin/ifconfig for each Room. None of this is defined beyond what you see and can deduce. It would be interesting to watch for changes in error counts. If error counts move faster for one unit compared to the others…

I’ll try keeping an eye on this. The status page is reporting a large number of PHY errors since the last reset. The number in one case was 2774417 for one of the players, but it does reset between refreshes. The most recent value was 12122. I have Jazz playing flawlessly from the Nas as I’ve been looking at these readings.


What is the source of the music that skips? Are you playing from a music service App, rather than starting play via a SONOS controller?


What is the source of the music that skips? Are you playing from a music service App, rather than starting play via a SONOS controller?

These skips are happening with the Sonos controller, which I nearly always use. 


Well, the music play from the Nas just stopped rather than skipped. I’m not sure if it was on the last song in the queue or not, but I suspect it was. I’m pretty sure that I have these skips on my wired One SL in the garage, but tomorrow I’ll play some music out there to check.


Consider the possibility of an NAS fail. There could also be some network issues. In the Windows desktop controller there is an Error Log in the Help panel. I never confirmed that this is a system wide log or a controller log.

At one point I replaced the router and reconfigured the DHCP range slightly. A few weeks later I started having some very intermittent failures associated with play from an ancient NAS, but they were not really consistent with a failing NAS. Eventually I thought about duplicate IP addresses, but I’m too smart for that, right? Finally, I swallowed my pride and checked IP addresses … darn! When I had reconfigured the DHCP range I forgot about a small, hidden away, seldom used device with a fixed IP address -- now shared with the NAS.


Hi @dan8558 

Thanks for your post!

The next time you hear this issue, please immediately submit a diagnostic and reply here with the number given when convenient. Thanks.


Several skips have happened tonight. The confirmation number is 1339777401.

 

Thanks!


Hi @dan8558 

Thanks for sending that.

First, it looks like your ethernet-wired Sonos devices are still relying on a wireless connection (wired to a mesh node, maybe?). Things will likely go better if you can instead get a device wired directly to the router, or to a switch that is in turn wired to the router.

However, the Sonos devices are unable to communicate to each other on your network effectively as they are being swamped by multicast packets that aren’t meant for them (the worst I remember seeing - there’s a lot). The main source of these has a MAC address of CA:52:AF:F0:21:40, but there are quite a few other sources. Finding that MAC address in your router’s connected client list should help you identify it.

If your router has an IGMP Snooping/Filtering option, I highly recommend you turn it on. That would filter out the multicast packets. The cheapest alternative would be to fit a IGMP-capable network switch to do the task instead. It’s possible that only a reboot of the router is required, however, so I recommend trying that first. Be sure to leave it unpowered for at least 30 seconds.

I also recommend you put all of your WiFi access points on channel 1 (two aren’t) and put SonosNet on channel 6 (Settings » System » Network » Change SonosNet Channel » 6) - only change the SonosNet when no rooms are missing from your app, and after fixing the IGMP. If rooms go missing after the change, change back to channel 1 to pick them back up and try again.

I hope this helps.


Hi Corry,

My wired Sonos devices are connected directly to either an access point or the router with the access points wired directly to the router. 

I’ve also switched all the access points and router to channel 1 from Auto. It was always my impression that they were always using channel 1, but apparently not.

I’ve identified the device with the MAC address you posted as being a phone. I’m going to buy a managed switch with the IGMP option today and I’ll set that up. We have a lot of devices in the house, but hopefully I can figure out how to reduce the multicast traffic without having to rely on the switch to deal with it all.

Thanks! I’ll let you know how it goes.


I think I’m going to buy a managed switch to help with the multicast traffic. I’m wondering about how to add it. Should I cable the new switch to my main router LAN port and then cable both access points to the switch rather than to the router LAN ports as they’re connected now?


Hi Corry,

I’ve installed a managed switch and enabled the multicast traffic control features, but I’m still having skips. I’m wondering if the problem continues to be multicast traffic, so I submitted a new diagnostic. The number is 95006550.

Thanks for any help you can provide.


Hi @dan8558 

I think I’m going to buy a managed switch to help with the multicast traffic. I’m wondering about how to add it. Should I cable the new switch to my main router LAN port and then cable both access points to the switch rather than to the router LAN ports as they’re connected now?

Yes - connect any and all ethernet connections via the IGMP switch, and connect the switch to the main router.

Hi Corry,

I’ve installed a managed switch and enabled the multicast traffic control features, but I’m still having skips. I’m wondering if the problem continues to be multicast traffic, so I submitted a new diagnostic. The number is 95006550.

Thanks for any help you can provide.

Unfortunately, I’m still seeing a massive amount of multicast flooding. Other errors are reported but multicast flooding is the likely cause of them all (limited bandwidth, bad Cloud Health and transport errors). This may be of additional help:

Sources of multicast flooding

Edit: The “Broadcast” type is essentially “multicast to all clients”, rather than specific ones, so is also causing problems.


Reply