Change tracks on Tidal take long time

[Remo_Schild]

Good day,

I hope you can help me with a problem I’m having with Roon.

I have a Roon Lifetime licence. After my original Roon server failed after around three years, I opted for a Silent Angel Z1C. It is currently running Roon version 2.61 (Build 1661).

Unfortunately, a problem I previously experienced with my old Roon server persists:

Whenever I change tracks on Tidal, Roon takes between one and two minutes to start playing the next track.

At first, I assumed this was due to the faulty Roon server. However, the new Silent Angel exhibits exactly the same behaviour, so I can now rule out a hardware fault.

To rule out potential sources of error, I have already taken extensive measures:

* New Silent Angel Z1C as the Roon server

* Completely new network infrastructure

* All devices hard-wired using Cat-8 cables

* Domestic wiring installed in 2025

* All network cabling checked by an electrician

* TIDAL account removed from Roon and reconnected (synchronisation took almost two hours)

Unfortunately, there has been no improvement.

The following points are worth noting:

* When I play music directly from my external NAS, tracks change immediately.

* When I use the TIDAL app directly, everything also works perfectly.

* The problem occurs exclusively in Roon, particularly when switching between tracks.

It therefore seems to me that the problem is not down to the network environment or the hardware, but could be directly related to Roon or the communication between Roon and TIDAL.

Do you have any idea what might be causing this behaviour, or what further diagnostic steps I should take? I’m also happy to provide you with log files or further system information.

Thank you in advance for your assistance. I look forward to your response.

Friendly regards

Remo

[vadim]

Hello @Remo_Schild

Thank you for reaching Roon support.

I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.

However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.

First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.

[Remo_Schild]

Hi Vadim, many thanks for your support. Following the list as requested.

Playlist started: 17:00:00
Track started playing: 17:01:32

Track changed: 17:03:00
Next track started playing: 17:03:50

Track changed: 17:03:59
Next track started playing: 17:04:45

Track changed: 17:05:00
Next track started playing: 17:06:10

Track changed: 17:09:10
Next track started playing: 17:10:30

While testing, I noticed something interesting:

When I skip to the next track in the playlist, the transition is noticeably faster than when I randomly select a different track from the library. In the latter case, the delay is significantly longer.

This behaviour is very unusual. I have never experienced this in the past, and I believe I have been struggling with this issue for approximately 6–7 months.

The TIDAL playlist I am using is the following:

https://tidal.com/playlist/1fefa224-cd7e-4b3a-ba64-9c817e90c0e7

[benjamin]

Hey @Remo_Schild,

Thanks for the fresh timestamps! We were able to compare the times you’ve shared with a fresh Roon Server diagnostic report, and in both cases, the “next track” file’s first block was already retrieved (pre-buffered) well before the stall started, and the actual Tidal API calls that eventually fire complete in under 500ms. So this isn’t network latency to Tidal, and the server isn’t resource-starved (GC pause and thread count are flat through both stalls). The delay looks like Roon Server itself sitting idle for ~30 seconds before it decides to advance the transport, consistent with an internal scheduling/queue-processing stall rather than a WAN/ISP/Tidal-side issue.

One structural detail that stands out: the play queue is logged as ordered count 8000 shuffle count 8000 , your Tidal playlist is being managed as an ~8,000-track in-memory queue, and every transition triggers a “queue got oversized, trimming N items” operation. That’s a plausible contributor on a low-power fanless device like the Z1C, and worth testing directly.

As an easy next step, can you test out a smaller subset of tracks and queue, something around 10-20 tracks?

I’d also be curious to see if adjust the DNS of your Server machine may help. We have seen users have a better experience in the past if they change their Router’s DNS servers from the ISP provided ones to Cloudflare DNS, Quad9 or Google DNS. Can you please give this a try and let me know if it helps?

Thank you!

[Remo_Schild]

Hi Benjamin, thank you very much for your feedback. Please see my comment below…

We were able to compare the times you’ve shared with a fresh Roon Server diagnostic report, and in both cases, the “next track” file’s first block was already retrieved (pre-buffered) well before the stall started, and the actual Tidal API calls that eventually fire complete in under 500ms. So this isn’t network latency to Tidal, and the server isn’t resource-starved (GC pause and thread count are flat through both stalls).

I can absolutely see why. It seems clear to me.

The delay looks like Roon Server itself sitting idle for ~30 seconds before it decides to advance the transport, consistent with an internal scheduling/queue-processing stall rather than a WAN/ISP/Tidal-side issue.

As I’d already had this problem with my old Roon Core (the original Roon server), I don’t quite understand this. I swapped the server (ultimately due to a fault – a case with which you are probably very familiar) for a new Silent Angel Z1C. This is configured to run 24/7; in fact, I can’t set it to do anything else. The network hardware has also been replaced, as I mentioned. Please read my first post carefully once again.

One structural detail that stands out: the play queue is logged as ordered count 8000 shuffle count 8000 , your Tidal playlist is being managed as an ~8,000-track in-memory queue, and every transition triggers a “queue got oversized, trimming N items” operation. That’s a plausible contributor on a low-power fanless device like the Z1C, and worth testing directly.

But the playlist only has 53 tracks – see the attached image. I simply can’t make sense of this information. Where on earth are all these tracks supposed to have come from? I’d never create a playlist of that size – I’d completely lose track of it . But yes, background music playlists can sometimes contain 300–500 tracks.
And as mentioned, I’ve noticed that the delayed track changes mainly occur when I want to skip several tracks in a playlist or when I want to listen to a different track from the library (which is being streamed to the playlist). The loading time of 1–2 minutes is the biggest challenge there. That’s why I’ve presented my list with the time blocks so clearly for you.

As an easy next step, can you test out a smaller subset of tracks and queue, something around 10-20 tracks?

See above

I’d also be curious to see if adjust the DNS of your Server machine may help. We have seen users have a better experience in the past if they change their Router’s DNS servers from the ISP provided ones to Cloudflare DNS, Quad9 or Google DNS. Can you please give this a try and let me know if it helps?

I’d be happy to give that a go. In that case, do I simply enter two DNS servers from the list above manually on the router?

Thank you very much for your help.

[vadim]

Hi @Remo_Schild

Thanks for catching that, it needed a closer look. The 8000-count in the diagnostic isn’t your current Tidal playlist, it’s the zone’s play queue, which accumulates past and future playback entries for that device over time rather than resetting between sessions. So it reflects your device’s ongoing playback history, not the 53 tracks in the playlist you tested with. That’s on us for not explaining it clearly the first time.

Correction to what we suggested earlier: there isn’t a queue view you can clear to test this. Instead, could you please try clearing the endpoint cache:

1. Create a fresh backup.
2. Stop Roon (or Roon Server).
3. Find and open your Roon or Roon Server folder: https://help.roonlabs.com/portal/en/kb/articles/database-location
4. Navigate to /Roon/Database/Registry/Core/.
5. Delete all the endpoint_ files in that directory.
6. Restart Roon.

Please let us know if that helps.

A couple more things to narrow this down. First, does this delay happen on every zone/output you have, or only on this specific one? Second, could you please check that zone’s audio settings (Settings > Audio > device setup for the zone) for “Fade” and “Resync Delay”? If either is enabled or set to a non-zero value, please try turning them off and testing again, they can add delay on top of whatever else is going on.

On DNS: yes, you’d enter the two addresses (for example 1.1.1.1 and 1.0.0.1 for Cloudflare) manually in your router’s DNS settings, usually under the WAN or internet connection section, in place of whatever your ISP has set by default.

And to be clear on the hardware point: you’re right, we’re not questioning that you already ruled it out by swapping both the server and the network end to end. The queue behavior is what we’re chasing now, not the hardware.

[Remo_Schild]

Thanks for catching that, it needed a closer look. The 8000-count in the diagnostic isn’t your current Tidal playlist, it’s the zone’s play queue, which accumulates past and future playback entries for that device over time rather than resetting between sessions. So it reflects your device’s ongoing playback history, not the 53 tracks in the playlist you tested with. That’s on us for not explaining it clearly the first time.

Sorry, I misunderstood it as well. I guess I’m not enough of a Roon expert either.

Correction to what we suggested earlier: there isn’t a queue view you can clear to test this. Instead, could you please try clearing the endpoint cache:

1. Create a fresh backup.

2. Stop Roon (or Roon Server).

3. Find and open your Roon or Roon Server folder: https://help.roonlabs.com/portal/en/kb/articles/database-location

4. Navigate to /Roon/Database/Registry/Core/.

5. Delete all the endpoint_ files in that directory.

6. Restart Roon.

Please let us know if that helps.

A couple more things to narrow this down. First, does this delay happen on every zone/output you have, or only on this specific one?

I have two zones, and the issue occurs in both of them. I have also tested it with individual devices as well as with multiple zones, but the behavior is always the same.

Second, could you please check that zone’s audio settings (Settings > Audio > device setup for the zone) for “Fade” and “Resync Delay”? If either is enabled or set to a non-zero value, please try turning them off and testing again, they can add delay on top of whatever else is going on.

Please see the attached screenshots.

On DNS: yes, you’d enter the two addresses (for example 1.1.1.1 and 1.0.0.1 for Cloudflare) manually in your router’s DNS settings, usually under the WAN or internet connection section, in place of whatever your ISP has set by default.

I will definitely try your suggested solution—I just haven’t had the chance to do it yet.

And to be clear on the hardware point: you’re right, we’re not questioning that you already ruled it out by swapping both the server and the network end to end. The queue behavior is what we’re chasing now, not the hardware.

Now for something quite interesting: Early this morning, Roon installed an update (see the third screenshot attached). Interestingly enough, everything is now working exactly as I would expect. Between 5:30 PM and 5:45 PM, I tested it extensively, and track changes were immediate and everything worked perfectly.

Could this have been fixed by the update?

How would you recommend we proceed from here?

Thank you very much for your continued support and assistance.

[benjamin]

Hey @Remo_Schild,

Our latest update did include several memory related optimizations that no doubt likely helped your Z1 overall.

For now, I’d leave everything as is and continue to test for the next day or so. We’ll keep this thread open, and we’ll monitor for your reply and results once you’ve had more time to review.

Thank you!

[Remo_Schild]

Thank you very much, Benjamin. I really appreciate all your support and the time you’ve taken to help me.

I’m quite busy at the moment, but I’ll do my best to test everything over the next few days.

If you don’t hear back from me, please assume that everything is working as expected. Otherwise, I’ll get back to you and reference this support case.

Once again, thank you very much for your excellent support. Wishing you all the best and have a great day!

Kind regards,

Remo

[noris]

Hi @Remo_Schild,

Thanks for the update. That sounds encouraging, and it makes sense to leave things as they are for now while you keep testing over the next day or so.

We’ll keep the thread open and watch for your reply and results once you’ve had more time to review. If we do not hear back, we’ll assume everything is working as expected. Otherwise, please come back and reference this support case.