Roon app on iOS skips track instead of pausing (ref#7TWO28)

Hi! What’s not quite right with Roon?

· Music won’t play or issues with my library

Music won’t play or issues with my library

· Streaming tracks greyed out or unavailable

Tell us what's going on

· Hitting Pause on iOS and Roon app skips track does NOT pause

Tell us about your home network

· nothing different than the last 2 years without issues

Issue is on Mac Roon app and iOS app. Click the pause button skips to the next track and I can not pause or stop my music!! Super frustrating!

Roon all updated to the latest. 2.58 Build 1608
Yes - I restarted my mac that is running RoonServer

Video:

Full log:

Part of log at Pause Button:

01/29 14:18:15 Info: [ui] [popups] Pause button clicked: play_pause()
01/29 14:18:15 Trace: [platformnowplaying/mac] MPNowPlayingInfoCenter: Connect
01/29 14:18:15 Trace: [platformnowplaying/mac] MPNowPlayingInfoCenter: Connect
01/29 14:18:15 Trace: [platformnowplaying/mac] MPNowPlayingInfoCenter: Connect
01/29 14:18:15 Debug: GMS: saving nav stack
01/29 14:18:15 Debug: GMS: done saving nav stack
01/29 14:18:15 Debug: GMS: saving nav stack
01/29 14:18:15 Debug: GMS: done saving nav stack
01/29 14:18:15 Warn: AddTopLevel: |tooltiplayout(1)
01/29 14:18:15 Debug: GMS: saving nav stack
01/29 14:18:15 Debug: GMS: done saving nav stack
01/29 14:18:15 Debug: GMS: saving nav stack
01/29 14:18:15 Debug: GMS: done saving nav stack
01/29 14:18:15 Debug: GMS: saving nav stack
01/29 14:18:15 Debug: GMS: done saving nav stack
01/29 14:18:17 Info: [stats] 405119mb Virtual, 116mb Physical, 276mb Managed, -160mb estimated Unmanaged, 3.06% of runtime in GC pauses, 2ms last GC
pause duration
01/29 14:18:18 Warn: frame took 17.69ms! 14.09ms preframe, 0.26ms safe queue, 0.02ms timers, 0.00ms frame calls, 0.02ms update, 17.69ms render
01/29 14:18:31 Warn: frame took 23.24ms! 16.35ms preframe, 0.09ms safe queue, 0.62ms timers, 0.00ms frame calls, 0.03ms update, 23.24ms render
01/29 14:18:32 Info: [stats] 405118mb Virtual, 57mb Physical, 181mb Managed, -124mb estimated Unmanaged, 2.77% of runtime in GC pauses, 1ms last GC p
ause duration
01/29 14:18:33 Trace: [push2] retrying connection in 0ms
01/29 14:18:33 Trace: [push2] exception thrown. restarting connection (OperationCanceled)
01/29 14:18:33 Trace: [client/roonbridges] network reachability changed, sending discovery query
01/29 14:18:33 Trace: [roonbridge] [sood] Refreshing device list
01/29 14:18:33 Debug: [easyhttp] [7] GET to https://api.roonlabs.net/push-manager/1/connect returned after 171 ms, status code: 200, request body siz
e: 0 B
01/29 14:18:33 Debug: [push2] push connector url received from push manager: ws://push-connector-v2-0.prd-roonlabs-1.prd.roonlabs.net/
01/29 14:18:33 Trace: [push2] connecting to push2 connector at ws://push-connector-v2-0.prd-roonlabs-1.prd.roonlabs.net/
01/29 14:18:33 Debug: [easyhttp] [9] POST to https://api.roonlabs.net/discovery/1/query returned after 179 ms, status code: 200, request body size: 7
4 B
01/29 14:18:33 Debug: [easyhttp] [8] POST to https://api.roonlabs.net/discovery/1/query returned after 206 ms, status code: 200, request body size: 1
40 B
01/29 14:18:33 Trace: [push2] connected to push2 connector at ws://push-connector-v2-0.prd-roonlabs-1.prd.roonlabs.net/
01/29 14:18:38 Debug: [easyhttp] [11] GET to http://127.0.0.1:9330/image/jhubaaaa.1by1_512.jpg returned after 157 ms, status code: 200, request body
size: 0 B

Hi @Bms,
As discussed I’ve now merged your update to here.

Thanks for sharing your report @Bms!

We’ll take a closer look and follow up with more information as quickly as possible.

In the meantime, could you please test out fully removing and reinstalling the Roon mobile app on your mobile device?

With that, let’s also refresh your Roon app database:

  • Exit out of Roon and safely stop Roon Server
  • Navigate to your Roon Database Location
  • Find the folder that says “Roon”
  • Rename the “Roon” folder to “Roon_old”
  • Reinstall the Roon App from our Downloads Page to generate a new Roon folder
  • Verify if the issue persists on a fresh database before restoring the backup

Thank you! :folded_hands:

Hi @Bms,

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:

  1. The selected Zone is a large, grouped Zone consisting of multiple networked endpoints

  2. 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:

[raat/tcpaudiosource] connecting to 192.168.1.11:0 
Error: connect failed: Can't assign requested address 
Warn: [raat/tcpaudiosource] disconnecting + retrying
  1. 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.

  2. 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.

  3. 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.

  4. 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:

[push2] exception thrown. restarting connection (OperationCanceled) 
[client/roonbridges] network reachability changed

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:

  1. First, ungrouped the Grouped Zone

  2. Restart or power-cycle the endpoint at 192.168.1.11 and confirm that it reappears cleanly in Settings → Audio before regrouping.

  3. 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’ll watch for your reply. Thank you!

1 Like

Hi @Bms,

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:

  1. ungroup the Grouped Zone in Roon

  2. Restart all your endpoints in the group

  3. Regroup the grouped Zone. Add any Zones connected via Ethernet first, and then any WiFi Zones afterwards.

  4. 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.

Thank you!