Sonos Play Pause Issue with Roon

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Sonos Play Pause Issue with Roon

Tell us about your home network

· WiFi and Wired. I use Switch between the Roon server and wifi. I use Wifi mesh from Asus. Recently changed the mesh from Synology. The issue was also present with Synology (prior to that TP link). Seems this is a persistent issue between Sonos and Roon.

2

Hey @Moh,

Thanks for writing in and for your report! We were able to review a fresh Roon Server diagnostic report and saw the following:

Roon isn’t the one pausing. Across the twelve days of logs, Roon sent exactly one pause command (Sept 7th at 14:50 local), and that one worked perfectly. Every other interruption came from the speaker’s side, the Sonos reported itself as paused or stopped while Roon still believed it was playing, and Roon did what it’s designed to do in that situation: assume you paused at the speaker and release the zone.

What that looks like in the Office (ERA 300): this is the one that actually kills playback:

  • Music is playing normally, then the ERA 300 spontaneously reports “paused.”
  • Roon ends the stream and moves on, starts a fresh stream, and the speaker confirms it’s playing again.
  • Two to three seconds later the speaker reports “paused” a second time, and at that point Roon gives up on the endpoint entirely and suspends the zone. That’s when you’d see playback dead and have to press play again.

The Living Room (Beam) shows a different, milder problem: four times on Sept 7th between 14:09 and 14:26, the Beam reported “stopped” at the very end of a track instead of rolling into the next one Roon had already queued up. Roon recovers by restarting the next track, so you’d hear a gap or a stutter rather than a full stop.

What we were able to rule out: the server itself was completely healthy at every one of these moments (no memory pressure, no stalls), your Sonos IP addresses were stable throughout September, and there isn’t a single failed command, timeout, or error against either speaker anywhere in twelve days of logs. Roon asked the speakers to play, they said yes, and then they told Roon they’d stopped.

Roon’s log records that the speaker reported a pause, not why, so we can’t close this from the logs alone, but there’s one strong clue. On Sept 16th at 19:22, Roon tried to renew its event subscriptions with the ERA 300 and all three came back rejected, meaning the speaker had already silently dropped Roon from its notification list. Speakers dropping subscriptions and delivering duplicate or out-of-order status events is a very typical signature of a network where some devices sit on a wired segment and others on wireless, which would explain why this has followed you across three different mesh vendors. It’s not really about the mesh brand.

A few things that would help:

  1. Check whether any Sonos speaker is wired to your switch while the rest are on Wi-Fi. This is the big one. A single wired Sonos puts the whole system onto SonosNet, and the resulting split between wired and wireless devices produces exactly this behavior. Either everything wireless, or check that your wired/wireless mix is deliberate.
  2. Set static DHCP reservations on the Asus for all your Sonos units and for your Roon Server.
  3. On the Asus: make sure IGMP snooping is enabled and consistent across all mesh nodes, and turn off band steering, client steering, and Airtime Fairness for the Sonos units. Also confirm the mesh nodes are bridging rather than routing, so everything stays on one subnet.
  4. Rule out something else grabbing the speaker: Sonos alarms, voice assistants, or an AirPlay/Bluetooth handoff would all produce this same “device paused itself” signature. Worth disabling alarms and any autoplay temporarily.
  5. A useful isolating test: play to the Office ERA 300 directly from the Sonos app for the same length of time. If it never drops that way but drops from Roon, we’re looking at the control channel. If it drops both ways, the speaker’s network link is the culprit.

One thing that would help us a lot: next time it happens, note the time. With that we can match it to the exact event in a fresh log set and see whether the speaker gave any reason.

Also, a quick question, is the Beam connected to a TV? A TV waking up or switching inputs can pull the Beam away from Roon, and that would explain the Living Room behavior separately from the Office.