Intermittent stalls on hi-res TIDAL playback due to CDN/peering issue (ref#D49K3Q)

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· Tracks take a long time to play

Please try to reboot your Roon Server

· Yes, rebooting helps, but the issue returns after some time

Please try to reboot your networking gear (Router/Switches/etc.)

· No, the issue is still the same even after a reboot

Is there any change in behavior if you try to navigate to Roon Settings -> Library and set both Background and On-Demand Audio Analysis to Throttled or Off?

· No, the issue is still the same

Does the issue happen on multiple Roon Remotes (controllers) or just one?

· Issue happens on multiple remotes

Router Domain Name System (DNS) change

· I was able to change my router's DNS servers but it did not help

What is the operating system of your Roon Server host machine?

· Linux Server (Ubuntu, Fedora, ArchLinux...)

Timestamp of issue occurrences

· All times below are local Pacific time (UTC-7). My RoonServer logs timestamp in local time. May 24, 2026, 9:56:02 PM — the worst event. A 24/176 hi-res stream delivered only 2327 kbps against a 7051 kbps requirement (33%), which triggered a sustained buffer starvation — "[prebuffer] sleeping in read" began firing at 9:56:05 PM and continued for nearly three minutes. There was also a related stall three minutes earlier at 9:53:06 PM (5086 kbps vs 7051 needed), and at 9:30:52 PM a stream collapsed to 545 kbps against an 1124 kbps minimum. May 27, 2026 — by far the worst day, with stalls clustered across the morning and midday: 7:29–7:31 AM — a single track (ti/4F653CAE) degraded continuously for over a minute, sitting around 4968–5516 kbps against a 7349 kbps requirement the entire time. 10:09 AM — another sustained degrade (ti/63C1357E), declining from 6405 down to 5905 kbps over roughly a minute. Further events at 11:58 AM, 12:00 PM, 12:24 PM, 12:29 PM, 12:48 PM, 12:52 PM, and again at 4:29 PM, 4:41 PM, and 4:58 PM — all hi-res, all under the required bitrate. May 31, 2026 — 5:08:49 PM (2876 kbps vs 5929 required, 48%) and 5:25:54 PM (5437 vs 5925). Every one of these is a hi-res stream (24/96 and above) from the CDN host lgf.audio.tidal.com. CD-quality and 24/48 streams play without issue. I can provide the full log extract on request.

Describe the issue

Hi,

I've been chasing intermittent stalls on hi-res TIDAL playback and I've narrowed it down enough that I think it's a CDN/peering issue on your end rather than anything local, so I wanted to hand over what I found.

My setup is a bare-metal RoonServer on wired gigabit, fiber internet (WAN sits at ~3.6ms RTT, 0% loss), DNS-over-TLS to Cloudflare. I've ruled out the local side pretty thoroughly — plenty of RAM and CPU headroom, clean NIC with no errors, sub-millisecond LAN, and the connection saturates fine on large direct downloads.

Over the last 7 days my logs show 69 "poor connection" events, and every single one of them is from the same CDN host: lgf.audio.tidal.com. Nothing from any other host. They're almost all on 24/176 and 24/192 FLAC — CD and 24/48 streams play perfectly. A few concrete examples:

- May 24: a full buffer starvation — "[prebuffer] sleeping in read" fired 523 times over 2 min 54 sec on a hi-res track, throughput sitting around 48% of what the stream needed.
- May 27: 31 separate poor-connection events in one day (by far the worst), all hi-res, all from lgf.audio.tidal.com.
- Worst single event in the logs: 2327 kbps actual against 7051 kbps required — 33% of minimum.
- Tonight (May 31): two more, 2461 kbps (80%) and 2694 kbps (44%), both on 24/176 FLAC.

The pattern's consistent: the edge node serving me just can't sustain the bitrate for 176/192k FLAC, while everything below that is fine. Looks like a peering or edge-routing problem specific to that node.

Could you enable diagnostics on my account and/or move me to a different TIDAL edge endpoint? Happy to pull exact timestamps for any of the above or reproduce on demand — just let me know what's most useful.

Thanks

Describe your network setup

Ziply Fiber, fiber, 2 Gig.
Topology: fiber ONT → pfSense firewall/router (running 2.8.1-RELEASE on a Netgate/custom box).
RoonServer runs on a dedicated bare-metal Ubuntu machine, wired gigabit (no Wi-Fi in the path to the Core). pfSense handles DHCP and DNS for the LAN; DNS is set to forwarding mode with DNS-over-TLS to Cloudflare.
Relevant measurements: WAN gateway RTT ~3.6ms with 0% loss; LAN latency to local endpoints is sub-millisecond; the Core's NIC negotiates gigabit full-duplex with no interface errors and effectively no dropped packets under load. Direct large-file downloads saturate the connection normally, so general throughput and the local network are healthy.
Endpoints are a mix of wired and Wi-Fi RAAT/AirPlay zones; the affected playback is on FiiO Q3 in the Family Room Zone, which is wired.

Hello @Jorge_Arias_Velasque, welcome to the community!

Thank you for the exceptionally thorough analysis — this is genuinely impressive diagnostic work.

Unfortunately, we are unable to reroute your TIDAL streams to a different CDN edge node — CDN routing and peering are entirely on TIDAL’s side and outside of our control. What you have identified is a congestion or peering issue specific to the lgf.audio.tidal.com edge node serving your region, and the fix needs to come from TIDAL’s infrastructure team.

We would strongly recommend taking this report directly to TIDAL support. The data you have — specific CDN hostname, timestamps, bitrate measurements, and the clear pattern of hi-res vs CD-quality — is exactly what their engineering team would need to investigate a peering issue. Most CDN providers can re-route problematic edge traffic once it is reported with this level of evidence.

In the meantime, one thing worth trying is enabling TIDAL MQA or lower quality tier temporarily for hi-res content to confirm the issue is purely bitrate-related, which your data strongly suggests.

Thanks for your quick response, @Vadim.

I’ve opened a support ticket with TIDAL as you suggested.

In the meantime, I switched the TIDAL service quality setting from Max to High, and that’s noticeably reduced the stalling — so the definitive fix for full hi-res is on their side, but I have a working setup for now.