Thank you for your patience. We’ve compared the Roon logs you’ve provided with the equivalent timestamp in the server logs. We’ve come to some conclusions and have a few suggestions to offer.
Here’s what’s happening:
The selected Zone is a large, grouped Zone consisting of multiple networked endpoints
Roon repeatedly attempts to connect to an endpoint at 192.168.1.11 using port 0, which is never a valid RAAT listening port and indicates that the endpoint is either offline, crashed, or left behind as a stale registration. The repeated failures are visible here:
Because this endpoint remains part of a large grouped zone, RAAT can’t tear down playback. It enters a retry loop while the Zones transition through buffering and clock re-selection.
You press Pause on the iOS Remote. The transport command lands while the Zone at 192.168.1.11 is already failing to transition into playback.
Instead of pausing cleanly, the engine advances the queue and attempts to reestablish playback on the next track. This is the expected response to a failed track initialization, but in this context, it presents as an unexpected skip to the next track.
This failure mode is far more likely in large grouped zones, where a single nonresponsive endpoint can block the entire group from reaching a stable Ready state.
The iOS Remote behavior aligns with this as well. The Pause command is registered normally in the UI, but shortly afterward the Remote restarts its push and discovery connections, indicating that the Roon Server session is no longer responding to control acknowledgements even though the app remains active and does not surface a connection error. This is visible in the logs you shared:
Because the underlying socket does not fully drop, the Remote appears connected while control commands silently fail.
This is obviously very technical and not a solution to your problem.
So, here is what you can actually do:
First, ungrouped the Grouped Zone
Restart or power-cycle the endpoint at 192.168.1.11 and confirm that it reappears cleanly in Settings → Audio before regrouping.
Now, regroup the Grouped Zone, add the endpoint at 192.168.1.11 to the group last.
If the endpoint no longer exists, it must be fully removed from the server’s view, which may require a server restart.
Once the invalid endpoint is cleared and re-added to the group, both the pause behavior and the Remote responsiveness should return to normal.
If this does not help, we’ll need to know a little more about the underlying network. Do you have a mesh network? Where is RoonServer connected relative to the endpoint at 192.168.1.11?
We wanted to reach out and see you’d had a chance to try some of the suggestions buried in my lengthy reply above.
From diagnostics, you were playing to a Grouped Zone when the symptom you wrote about occurred. Is that correct? If so, here’s a simplified version specific test we’re looking for:
ungroup the Grouped Zone in Roon
Restart all your endpoints in the group
Regroup the grouped Zone. Add any Zones connected via Ethernet first, and then any WiFi Zones afterwards.
Try to reproduce this issue with iOS control and track skipping
Let us know the name of the track or album that you played in Roon, and we’ll pinpoint the event in logs.