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.

[Remo_Schild]

Hello everyone, I’ve been monitoring the issue over the past week, yesterday and today. I was away for a few days, during which time the system was inactive.

Last week, when I restarted the Roon server (just the Roon server software), everything was working very well.

As I mentioned, I’ve been away for a few days; yesterday I wanted to listen to music again and it was a disaster. It took between 2 and 3 minutes for a track to start playing. Absolutely terrible performance.

I then restarted the Roon server (just the Roon server software) again and everything went back to normal. It was working as expectable. I didn’t touch the C1Z (Silent-Angel).

I’ve noticed that, over the past few days since restarting the Roon server (just the Roon server software), the problem has been getting worse and worse. This isn’t a good situation for me, and I don’t know why it’s happening.

As I’ve already mentioned, I had the same problem with my old Nucleus server, but ‘only’ for a short time, as it then (as you know) broke down.

What do you make of this? It seems to be a problem that develops over the course of several days (even when the system is idle).
Many thanks in advance for your support. Regards R.

NB: Perhaps one more thing – during the day, I mostly just listen to the radio; it’s usually only in the evening that I actively listen to music. Just thought I’d mention that.

[Remo_Schild]

Hello everyone, I was able to look into this in more detail over the weekend and listened to some music. I still can’t work out what’s causing the system to slow down, but it started slowing down again and I had to restart only the Roon server (just the Roon server software). After that, it’s been running quickly again until today.

I’ve also noticed that my queue isn’t clearing, and depending on how many tracks I add to it, it can get quite long. Could this be related?

Many thanks in advance for your help and support.

[benjamin]

Hey @Remo_Schild,

Thanks for the update and additional information!

Our development team has recently released some additional memory related optimizations over on our current Early Access branch of Roon (build 2.71) which will eventually make it into our next full Production update, which you’ll be auto-prompted with.

I believe these additional updates will take you across the finish line for steady performance moving forward.

Until you get the prompt to update, the best workaround would be a daily reboot of Roon Server within your current machine.

You can also explore migrating over to Early Access if you’d rather give it a try sooner, here’s more info:

Roon Early Access Program

Thanks for your longstanding patience here!

[Remo_Schild]

Thank you very much, Benjamin, for your feedback. I can deal with that and will wait for the effective release. Can you give an indication of when this will be?

And could you perhaps say a bit more about where exactly I’ve gone wrong, or what the actual problem with my installation is?

I’m not quite sure myself – or have I missed something? Thank you very much for your help. BRR.

[benjamin]

Hey @Remo_Schild,

We’re not able to comment on specific timelines, but it won’t be all that long before the next update.

@Remo_Schild

And could you perhaps say a bit more about where exactly I’ve gone wrong, or what the actual problem with my installation is?

I don’t believe there are any specific problems with your current installation, our development team has made additional improvements over on Early Access, which is a different branch of Roon, and so those improvements have yet to reach your specific server.

I don’t believe you’ve missed anything here!

[Remo_Schild]

Thank you very much, Benjamin, for your feedback. I’m not entirely satisfied with your answer yet. I’ve been working in the software industry for 25 years and I know that answers aren’t always straightforward or easy to provide.
Nevertheless, I’m wondering where the challenges lie. Is the behaviour I’m experiencing down to the Roon server itself, or is it due to an interface?
I’d just like to learn a bit more, for my own peace of mind.
Thank you very much.

BRR.

[connor]

Hi @Remo_Schild,

We’re revisiting this case and wanted to share some notes.

Diagnostic logging shows two things occurring during the timeframes around the dropouts you’ve reported in this topic thread.

1. A WiiM Sound reports a server-side buffer overrun while preparing to transition from one track to another.

2. A Bluesound N330 is reporting sample dropouts during playback. Data sent from RoonServer isn’t reliably reaching that endpoint during high-resolution RAAT playback.

It’s worth noting that these two errors are source-agnostic, in that they both occur during both Tidal and Live Radio playback.

Can you please elaborate on the actual network pathway between your current Roon Server machine and these two devices? Do any second routers, mesh nodes, or network switches sit in between them? These dropouts won’t necessarily be caused by inadequate network hardware, but in fact, quite the opposite. Many highly customizable routers or mesh setups can accidentally interfere with Roon’s sustained TCP connections by attempting to optimize traffic.

We’ll watch for your reply and proceed from there. Thank you!

[Remo_Schild]

Hi Connor

Thank you very much for your interesting and detailed explanations. I really do appreciate your support.
I’ve tried to provide you with a printout of my home network topology. Unfortunately, AVM doesn’t seem to offer a particularly useful print or export function – or perhaps I just haven’t found it yet. I hope, nevertheless, that the attached overview will be of some help to you.

I’ll try to give you a basic description of the setup:
• Internet access via Huawei – fibre-optic router operating as a modem
• FritzBox – router, Mesh master, DHCP server
• Zyxel switch (not a smart switch), used solely for distribution
• Fritz-repeater (living room) – mesh client – wired
• Moon music amplifier – wired
• Wiim Sound – kitchen – wireless
• Various Siemens household appliances – wireless
• Fritz-repeater (office) – mesh client – wired
• Bluesound PowerNode 1 – wired
• Bluesound PowerNode 2 – wired (back in use since last Friday; had been out of service for a long time)
• Wiim Sound – Bedroom – wired
• Fritz repeater (Laundry) Mesh client – wireless
• Wiim Sound – Bathroom – wireless
• Various iPads, iPhones, MacBooks, Mac Minis – all wireless

• Loxone home automation system, solar inverter, heating, doors/access, roller shades, etc. – all controlled centrally

• All network components are new and have been replaced

First, a bit of background on my setup: My house is a new build from 2024/2025. The entire network infrastructure is state-of-the-art, fully hard-wired, and was professionally installed and tested.

What I find particularly fascinating is that this challenge has been with me for several years now – even though my hardware has undergone several fundamental changes.
• It all started with Sonos. Even back then, similar problems arose, albeit much less frequently. About once a quarter, I had to restart the entire system to get everything working reliably again.
• When I switched to Roon, Sonos became redundant for me, so I switched to Bluesound. As I wasn’t entirely satisfied with that, I switched to WiiM components around nine months ago.
• As part of my new speaker setup, I also integrated a MOON 371 about twelve weeks ago.

Despite all these changes, one thing has remained surprisingly constant: the actual challenge has never changed. That’s why I’m finding it increasingly hard to believe that the cause lies solely with the hardware or the network.

One question in particular is on my mind: following your recommendation, I regularly restart the Roon Server. I would actually expect the system to start up in a ‘clean’ state afterwards. At the same time, I’ve noticed that all settings – for example, the grouping of my listening zones – are retained in full.
Hence my question: is this behaviour intended, or shouldn’t a restart at least reset certain cached information?

I look forward to your assessment and thank you once again for your support. BRR.

[benjamin]

Hey @Remo_Schild,

Thank you for the thorough write-up and the network diagrams, that’s genuinely one of the most useful topology descriptions we get, and it let us line up your setup against the fresh Roon Server logs precisely. Let me share what we found.

Your hardware history actually points toward the answer, not away from it. You’re right that the problem survived Sonos, then Bluesound, then WiiM, and I understand why that makes a hardware/network cause feel unlikely. But the one thing that never changed across all three generations is the pattern: synchronised multi-room groups playing to endpoints that reach the network over Wi-Fi. Roon’s audio transport (RAAT) keeps every endpoint in a group sample-accurately clock-synced in real time, which makes it far less forgiving of small timing hiccups than Sonos or AirPlay, which hide them behind large buffers. So the same marginal wireless path that Sonos papered over tends to surface in Roon as dropouts. The constant across the years wasn’t the brand, it was grouping over wireless.

What the logs show. Over the ten days we reviewed, every single dropped/killed stream and every buffer error occurred on a grouped zone that included your wireless WiiM zones. Your solo zones, and your wired-only group (Office + Bluesound), played cleanly the entire time, no errors at all. The tell-tale sign is a run of RAAT “sync timeout” messages to a WiiM immediately before the group’s stream is torn down. In one case the error was even reported against your wired MOON 371, but only because it was grouped with a WiiM that had stalled; the MOON itself was fine. And notably, one of these failures happened on a 128 kbit/s internet-radio stream, which tells us this isn’t about bandwidth or high-resolution files at all, it’s about timing and synchronisation across the group.

A quick test that will make this visible to you. If you’d like to confirm it yourself:

1. Group only your wired endpoints (e.g. MOON 371 plus a wired Bluesound) and play something for a while, this should be rock-solid.
2. Then add a single wireless WiiM (Kitchen or Bathroom) to that same group and play the same content.

If the dropouts return only after the wireless endpoint joins, we’ve located the mechanism precisely.

What will actually resolve it:

• Where you need whole-home synchronised groups, the WiiM endpoints really do need a wired connection. Grouping Wi-Fi endpoints with wired zones is the specific combination that fails.
• Your laundry repeater is running on a wireless mesh backhaul, so any audio endpoint behind it is effectively two wireless hops from the router, the hardest case for RAAT. I’d avoid placing audio endpoints there, or give that repeater a wired backhaul.
• On the FritzBox, set a fixed IP (DHCP reservation) for each Roon endpoint. We can see at least one device has already changed address between captures, and re-addressing forces Roon to re-establish connections.

On your restart question, this is a great observation, and the behaviour is intentional. Your zone groupings, settings and library live in the Roon Server database, which is persistent by design; a restart is not meant to reset them, so nothing is stuck or corrupted there. What a restart does clear is the transient, in-memory state, the live audio connections and device discovery. So retained zone groups after a restart are exactly what we’d expect. One thing worth mentioning: the logs for this period show the Roon Server software itself started only once, so whatever restart you’ve been performing may not be cycling the Roon Server process. In practice, if you want to clear a stuck audio path, power-cycling the endpoints (the WiiMs / repeaters) tends to help more than restarting the server.

If you run the test above, share the result and we’ll take it from there.

[Remo_Schild]

Hi Benjamin,

Thank you very much for your support and your detailed explanations. I really do appreciate it.

However, there’s one point I’d like to emphasise again so that we don’t lose sight of the main issue. The actual problem with my Roon server isn’t the occasional loss of a stream, but the extremely slow performance .

Specifically, it sometimes takes up to two minutes for a newly selected track to actually start playing. That is precisely the challenge I’ve been trying to resolve for month s .

I can understand that a stream might be interrupted occasionally. For me, this happens almost exclusively with internet radio. With TIDAL playlists, on the other hand, it hardly ever happens. For me, such interruptions are, to a certain extent, part and parcel of the quality of the service or the streaming provider in question. As Roon uses these services, it is ultimately also dependent on their availability and quality – or am I mistak e n?

What I find interesting, however, is this: when I listen to music directly from my Synology NAS, these delays do not occur at all. That makes sense to me, as in this case all communication takes place within my home network and no internet connection is requi r ed.

That’s why I’d like to emphasise once again: the main problem isn’t the loss of a stream, but Roon’s exceptionally slow response when searching for, selecting and playing a track. In my view, that’s exactly what we should be focusin g on.

---

---

---

--

Thank you for the thorough write-up and the network diagrams, that’s genuinely one of the most useful topology descriptions we get, and it let us line up your setup against the fresh Roon Server logs precisely. Let me share what we found.

Your hardware history actually points toward the answer, not away from it.You’re right that the problem survived Sonos, then Bluesound, then WiiM, and I understand why that makes a hardware/network cause feel unlikely. But the one thing that never changed across all three generations is the pattern: synchronised multi-room groups playing to endpoints that reach the network over Wi-Fi. Roon’s audio transport (RAAT) keeps every endpoint in a group sample-accurately clock-synced in real time, which makes it far less forgiving of small timing hiccups than Sonos or AirPlay, which hide them behind large buffers. So the same marginal wireless path that Sonos papered over tends to surface in Roon as dropouts. The constant across the years wasn’t the brand, it was grouping over wireless.

I can see your point and understand your expl anation.

What the logs show.Over the ten days we reviewed, every single dropped/killed stream and every buffer error occurred on a grouped zone that included your wireless WiiM zones. Your solo zones, and your wired-only group (Office + Bluesound), played cleanly the entire time, no errors at all. The tell-tale sign is a run of RAAT “sync timeout” messages to a WiiM immediately before the group’s stream is torn down. In one case the error was even reported against your wired MOON 371, but only because it was grouped with a WiiM that had stalled; the MOON itself was fine. And notably, one of these failures happened on a 128 kbit/s internet-radio stream, which tells us this isn’t about bandwidth or high-resolution files at all, it’s about timing and synchronisation across t he group.

A quick test that will make this visible to you.If you’d like to confirm it yourself:

1. Group only your wired endpoints (e.g. MOON 371 plus a wired Bluesound) and play something for a while, this should be rock-solid .

2. Then add a single wireless WiiM (Kitchen or Bathroom) to that same group and play the s ame conten t.

If the dropouts return only after the wireless endpoint joins, we’ve located the mechani sm precise ly.

I can see that too, and I understand you r explanation.