Roon ARC Initial Track Play Fails Due to Session Begin Latency (ref#N3TX11)

Support
1

What best describes your playback issue?

· Music doesn't start when I press "Play"

What type of Zone is affected by this problem?

· *Network Zones* are affected.

Is the affected network Zone connected with Ethernet or WiFi?

· WiFi

Does the issue affect all file formats?

· The issue affects *multiple/all* file formats.

Does the issue happen with local library music, streaming service music, or both?

· *Only streaming* music is affected.

Please select the streaming service(s) with which you're encountering playback problems.

· TIDAL

Have you tried logging out and back in again to your streaming service in Roon Settings?

· Logging out and back in had no impact, the issue remains

Do you have an approximate timestamp of when the issue last occurred?

· Most recent: Aug 5 2026, 12:31 PM Eastern (16:31:04-16:31:15 UTC) - "If Love Is A Skill", "Changes", "Oh! You Pretty Things", and "Feel" all failed at 0% in a row. Earlier same day: 7:32-7:33 AM Eastern (11:32:32-11:33:27 UTC) - "Is This Love" (TIDAL 277080645) and "If Love Is A Skill". Full UTC windows with matching swim/session/begin latencies are in the description.

What are the make and model of the affected audio device(s) and the connection type?

· iPhone running the current Roon ARC app. In the car: CarPlay to the vehicle head unit. At home: phone output directly. Only ARC is affected - all home RAAT zones play from the same core without issues. The failures happen in the ARC app itself regardless of whether CarPlay is attached.

Describe the issue

At the start of every fresh Roon ARC session (iPhone 16 Pro, usually CarPlay in the car, but it also happens at home on Wi-Fi), the first 1-5 play attempts of TIDAL tracks fail immediately with "an unexpected error occurred". Skipping to another track and retrying eventually works, and once the first track plays, the rest of the session is flawless (every later track scrobbles at 100%).

Server logs show the failures line up exactly with the core's call to POST https://api.roonlabs.net/swim/1/session/begin?tidal=max taking 10-18 SECONDS when a new streaming session starts. The same endpoint returns in 80-160 ms for periodic background calls, and other api.roonlabs.net calls made in the same seconds (e.g. /metadata/1/tracks/translate) return in under 200 ms, so this looks specific to the swim session-begin path on the cloud side, not my network.

Evidence from RoonServer_log.txt (timestamps UTC):
08/04 19:54:59 [easyhttp] POST swim/1/session/begin?tidal=max returned after 10992 ms, status 200
08/04 22:30:20 [easyhttp] POST swim/1/session/begin?tidal=max returned after 18172 ms, status 200
08/05 11:36:46 [easyhttp] POST swim/1/session/begin?tidal=max returned after 11256 ms, status 200

Correlation: on 08/04, "Make Me Feel" failed five times at 0s/186s (0%) between 22:26:43 and 22:27:27 UTC; the 18.2 s session/begin completed at 22:30:20 and the same track then played to 100% at 22:30:32. On 08/05, "Is This Love" (tidal track 277080645) failed twice and "If Love Is A Skill" failed at 0% between 11:32:32 and 11:33:27 UTC; after the 11.3 s session/begin completed at 11:36:57, playback worked for the rest of the drive. On 08/05 at 16:31:04-16:31:15 UTC, four tracks failed in a row at 0% while the core was tearing down the previous expired swim session.

Possibly related, recurring every 4 hours: "couldn't get keypair 0d808b4d-...: Result[Status=NotFound]" (HTTP 404 from roonmobile.roonlabs.net), which looks like a stale ARC keypair registration.

Setup: Roon Server 2.71 (build 1680) production on Ubuntu 26.04 LTS, Intel NUC, 16 GB RAM; server healthy during all incidents (1.8 GB RSS, no swap, load 0.05). Library 8,721 tracks. TIDAL (Max) and Qobuz. ARC connects through a WireGuard relay on AWS because my fiber ISP uses CGNAT; the relay is verified NOT the issue, since during the failure windows ARC API requests (/pages/home, /sync) were served in under 200 ms over the same path, and the core's outbound HTTPS to api.roonlabs.net goes directly out the fiber line, not through the tunnel. Core ID: 97c0aa74-7c44-45e0-8e27-614303a48467.

Request: please check server-side latency on swim/1/session/begin for TIDAL session starts. The UTC windows above should be easy to find on your side; happy to enable diagnostics if needed.

Describe your network setup

FairlawnGig fiber ISP (CGNAT, no public IPv4) -> Ubiquiti UCG-Fiber router (192.168.20.1, DHCP/DNS) -> Intel NUC Roon Server wired via gigabit Ethernet (192.168.20.10). Because of CGNAT, ARC port 55000 is forwarded through a WireGuard tunnel from the NUC to an AWS EC2 relay instance (Ohio); ARC connectivity test reports Success with the relay's public IP. Phone uses Verizon LTE in the car or home Wi-Fi (same UCG-Fiber). Note: the ARC data path through the relay is fast and verified working during the failure windows; the slow calls are the core's own outbound HTTPS to api.roonlabs.net, which goes directly out the fiber line, not through the tunnel.

2

Hello @Eddie_Hajek

Thanks for the detail, and for the log work. We want to save you from spending more time on it, because it is pointing in the wrong direction.

Roon Server does not handle Roon ARC playback. When you play a streaming track in Roon ARC, the server provides metadata and playback information, and the audio itself comes to your phone directly from the streaming service. It does not pass through your Roon Server. The swim/1/session/begin calls you found are not on the Roon ARC playback path, so their duration does not gate whether a track starts on your phone.

We checked this against a live Roon ARC session on our side. During that session, one of our own cloud endpoints returned a 504 after nine seconds, and Roon ARC played the track without any problem. Slow calls from the server do not stop Roon ARC playback.

The same goes for the keypair NotFound entries. Those appear on healthy sessions too and are not an error you need to act on.

That puts the focus on your phone’s connection to TIDAL, which is where the audio actually comes from. A few things would help.

First, you have both TIDAL and Qobuz. Please could you start a fresh Roon ARC session and play a Qobuz track as the very first track. If Qobuz starts cleanly while TIDAL fails in the same conditions, that points at the TIDAL side specifically.

Second, you mentioned this happens both in the car on cellular and at home on Wi-Fi. Please could you also try a fresh Roon ARC session on a third network away from home, for example at a workplace or on public Wi-Fi. If it fails there too, the problem is following the phone rather than any one network.

Third, please sign out of TIDAL in Roon Settings, sign back in, then force quit and reopen Roon ARC on the phone so it starts from a fresh session rather than reusing a cached one. You mentioned trying the sign out and back in already, but the force quit on the phone matters as well.

Fourth, when a failure happens, please note whether the phone was on cellular or Wi-Fi at that moment, along with the exact time and timezone.