Persistent TIDAL logouts and track-transition stalls on ROCK NUC10i5FNH (ref#IWY3E4)

Support
1

Tell us what's going on

Persistent TIDAL logouts and track-transition stalls on ROCK NUC10i5FNH

Core Machine (Operating System / System Info / Roon Build Number):

  • OS: Roon Optimized Core Kit (ROCK) - OS Version 10.0.0.110
  • Hardware: Intel NUC 10 Mini PC (NUC10i5FNH)
  • RAM: 16GB (2x8GB Kingston FURY DDR4-2666 SODIMM)
  • OS Drive: 250GB Samsung 970 EVO Plus NVMe M.2 SSD
  • Internal Storage Drive: 1TB Samsung 870 EVO SATA 2.5" SSD
  • Roon Server Version: Version 2.71 (build 1683)

Network Details:

  • Router Model: Rogers Xfinity Gateway Gen 3 (10.0.0.1)
  • Connection: ROCK NUC is hardwired via Gigabit Ethernet to local network.
  • IP/DNS Configuration: Configured with a static IP (10.0.0.110) and custom DNS (1.1.1.1). Rogers Advanced Security is verified OFF.
  • Audio Endpoints & Remotes:
  • Remotes: MacBook Pro M4 Pro, iPhone 14, Samsung Galaxy Tab A7 Lite (SM-T220)
  • Audio Endpoints: NAD C 658, WiiM Ultra, Topping E50

Description of Issue:

I have a paid Lifetime Roon subscription and have used TIDAL with Roon for four years. For several months, I have experienced recurring TIDAL disconnections and track playback delays:

  1. Frequent Disconnections & Auth Loops: TIDAL unlinks unexpectedly, showing "TIDAL login failed" or "Not configured". Web authentication succeeds with "You've successfully connected your TIDAL account," but handoff back to Roon hangs with "Waiting for TIDAL login" and times out.
  2. Inter-Track Playback Freezes: Even when logged in, playing TIDAL content frequently hangs for 1–2 minutes specifically during track transitions (e.g., between tracks 3 and 4 of an album), while active track streaming itself runs without bandwidth issues.

Troubleshooting Steps Completed:

  • Verified active TIDAL subscription on web/native app.
  • Rebooted NUC / RoonServer via WebUI multiple times.
  • Set Static IP (10.0.0.110) with Cloudflare DNS directly on ROCK.
  • Confirmed Rogers Advanced Security is disabled.
  • Cleared RoonServer/Cache directory via SMB.
  • Removed tidal_account file from Database/Registry/Core to reset tokens.
  • Set Resync Delay to 0 ms on active audio zones and cleared the playback queue.

Please pull diagnostic logs from my ROCK Core to trace the underlying transport and token handoff errors.

2

Hello @SteadilyFred

Your account, your tokens, and your Roon setup are all fine. The problem is that requests from your server to Tidal’s API are not coming back.

Over nine days of logs, August 22 to 31: 332 of 1,464 calls to api.tidal.com timed out, just under a quarter. None of them were refused or rejected. They simply got no answer.

While that was happening, your server was talking to Roon’s own services normally. Inside those same timeout windows we counted 7,116 successful requests to Roon, at a median of 260 milliseconds. So your internet connection, your DNS, and your server are all working. It is specifically the route to Tidal that drops out.

It comes in episodes rather than at random: 92 of them, some a single failed call, the longest about ten minutes.

That accounts for both of your symptoms. Roon revalidates the Tidal session every two hours, and when that call times out the session goes into an error state, which is the “TIDAL login failed” message. Separately, at the end of each track Roon has to ask Tidal where the next one streams from, and when that call times out playback stops. A healthy version of that call answers in about 195 milliseconds.

One thing on our side. When that call goes unanswered, Roon currently waits 100 seconds before giving up, then stops without trying again. That wait is your one to two minute freeze, and we are raising it internally today with your logs.

What we would like you to try. Please change the DNS on your ROCK from 1.1.1.1 to Google’s, 8.8.8.8 and 8.8.4.4, leave everything else exactly as it is, and use Roon normally for a day or two.

Tidal’s API sits behind a content delivery network, and which of their servers you are sent to depends on who answers your DNS lookups. This is a test rather than a known fix, but it changes one variable cleanly and it takes a minute to undo.

Also, please do not delete the Tidal account file or clear the cache again. Those were reasonable things to try, but nothing is wrong at that level, so they cannot help.

Please let us know how it behaves after a day or two.

3

Thanks for the detailed diagnostic breakdown, @vadim. I updated the DNS setting on my ROCK NUC to Google DNS (8.8.8.8) as requested and monitored playback over the last two days.

Here are the results:

  1. Authentication: The login dropouts and verification loops persist.
  2. Track-Transition Stalls: Unfortunately, changing to 8.8.8.8 did not resolve the inter-track hanging issue. Playback still randomly freezes for ~100 seconds when transitioning between tracks or manually selecting a new track/album after several songs play successfully.

(Note: The ROCK WebUI only has a single text field for DNS, so I entered 8.8.8.8 as instructed).

Since 8.8.8.8 did not clear up the api.tidal.com timeout calls, are there alternative DNS resolvers or network-level tests you would like me to run next?

4

Hello @SteadilyFred

DNS is ruled out. Across the days on 8.8.8.8 the timeout rate did not move: 25% over the whole window, and September 2 was the worst day in the set at 38%. Please put the resolver back to whatever you prefer, or leave it as it is. It makes no difference either way, and no other resolver is worth trying.

The logs do narrow it, though. Requests for the audio itself, which go to a different Tidal host, did not time out once in 322 calls. Only api.tidal.com and tidal.com fail. And in 46 cases a request hung for the full 100 seconds while a second request to the identical URL, sent while the first was still waiting, came back in about 200 milliseconds. On August 31, a call for one track’s playback details hung from 02:56:07 to 02:57:48, and a second call for the same track started at 02:57:10 and answered in 237 ms.

What we need next is which address your server is actually connecting to when a call hangs. We have turned on the additional logging for that on your machine, and it only takes effect at startup.

Please do the following:

  1. Shut the NUC down from the ROCK web interface, remove power for about ten seconds, and start it again. Then do it a second time.
  2. Use Roon normally for a day, and if you can, play a few albums straight through to bring on the track-transition stalls.
  3. Let us know once you have a few, with a rough time for one or two of them.

We will pull the logs from here.

5

@vadim, thank you for the detailed analysis and for turning on the extra logging. I’m glad my setup and hardware appear to be working properly.

I have completed the two cold reboots via power cable disconnection to ensure the new diagnostic flags are active. During my brief testing on 2026-09-03, I experienced track-transition stalls at the following times (MDT, UTC/GMT -6):

• 10:35
• 12:06
• 12:21

Please pull the updated logs when convenient and let me know what the IP tracing reveals.