Roon Server download loop causing excessive requests to Akamai (ref#61XRFT)

Dadoo · March 18, 2026, 2:54am

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· App interface looks or behaves oddly

Tell us what's going on

· Roon Server's retry strategy to download music files may result in a loop that floods Akamai with download requests that return an HTTP 200 status code but not the actual file. Qobuz reports the requested file is 57.4 MBytes, but Roon Server logs show that result is "first block: 0 blocks read: 0". The download is interrupted due to missing block 0 and a new download request starts. On Mar 17th, this repeated 10s of thousands of times.

Tell us about your home network

· Xfinity internet
\_ Netgear Nighthawk CM2000
\_ Firewalla Purple (router mode)
\_ Eero Pro 6 (bridge mode)

Dadoo · March 18, 2026, 3:11am

A Roon remote stopped playing a song and seemed stuck. Pressing the pause and play button did not result in the song continuing. Only by skipping to the next song in the queue did the music continue playing. Odd behavior but I considered it a momentary network glitch with Qobuz’s platform.

After a while, I noticed that a Grafana chart I used to track Qobuz download speeds stopped showing data points:

At the timestamp when the chart stopped showing data, this was in the Roon Server logs:

03/17 01:06:27 Debug: FTMSI-B-OE qo/531A4FB7 rid:1 request ended – first block: 0 blocks read: 0 download speed: -256kbps response time: 153ms

To find how often the “-256kbps download speed” entry appears in the log files I executed the following commands from the Mac OS terminal:

find ~/Library -type d -maxdepth 1 \( -iname 'roon*' -o -iname 'raat*' \) -print0 | \
xargs -0 -I{} find {} -maxdepth 1  -type d -name 'Logs' -print0 | \
xargs -0 -I{} grep -r -- '-256kbps' {} | \
awk -F':' '{print $2":"$3":"$4"\t"$9}' | \
sort

Which produced:

03/14 18:37:39 Debug -256kbps response time
03/14 18:37:40 Debug -256kbps response time
03/14 18:37:40 Debug -256kbps response time
03/14 22:49:03 Debug -256kbps response time
03/15 01:17:47 Debug -256kbps response time
03/15 22:43:48 Debug -256kbps response time
03/15 22:43:50 Debug -256kbps response time
03/16 17:56:25 Debug -256kbps response time
03/16 20:41:06 Debug -256kbps response time
03/16 20:41:11 Debug -256kbps response time
03/17 01:05:38 Debug -256kbps response time
-----8<—snip—8<—snip—8<—snip—8<----

Roon Server continued to request the same audio file:

03/17 36,937 times

Here’s the relevant log entries that show what’s happening. The pattern of creating new requests repeats thousands of times without pause. Note the references to cache item “qo/531A4FB7”.

03/17 01:06:27 Info: FTMSI-B new FileCache qo/531A4FB7

/Users/me/Library/RoonServer/Cache/smc.db/bfc/237.cache
https://streaming-qobuz-std.akamaized.net/file
03/17 01:06:27 Debug: FTMSI-B Cache open file qo/531A4FB7 domain: zoneplayer:16 ordinal:137
03/17 01:06:27 Debug: FTMSI-B qo/531A4FB7 download status: DownloadNotStarted accessTimeout:False openFiles:1 prev:no
03/17 01:06:27 Trace: FTMSI-B 7 FileCache qo/531A4FB7 dwStatus:DownloadNotStarted files:1 accessTimeOut:False priorities: (‘zoneplayer:16’:137) → bw limit:0kbps
03/17 01:06:27 Debug: [easyhttp] [8698] GET to https://www.qobuz.com/api.json/0.2/track/getFileUrl?format_id=27&intent=stream&request_sig=d3d28b2325fb1762b73df36eeaeeef63&request_ts=1773727586&track_id=342289703 returned after
338 ms, status code: 200, request body size: 0 B
03/17 01:06:27 Info: [iMac] [zoneplayer] Queueing: https://streaming-qobuz-std.akamaized.net/file
03/17 01:06:27 Info: FTMSI-B 7 FileCache qo/531A4FB7 dwStatus:DownloadNotStarted files:1 accessTimeOut:False priorities: (‘zoneplayer:16’:137) → bw limit:51200kbps

03/17 01:06:27 Debug: FTMSI-B-OE qo/531A4FB7 created new req 1 for block 0 p 4294967295; active requests 1
03/17 01:06:27 Debug: [easyhttp] [8702] GET to https://streaming-qobuz-std.akamaized.net/file?uid=3089804&eid=342289702&fmt=7&profile=raw&app_id=188245549&cid=2202808&etsp=1773731187&hmac=oq4BiRTBSx4zTCnP27xnUd-pqMg returned a
fter 153 ms, status code: 200, request body size: 0 B
03/17 01:06:27 Debug: FTMSI-B got length for qo/531A4FB7; 57.4 MBytes
03/17 01:06:27 Debug: FTMSI-B qo/531A4FB7 download status: FileLengthRetrieved accessTimeout:False openFiles:1 prev:(DownloadNotStarted,False,1)
03/17 01:06:27 Debug: FTMSI-B-OE set min bandwidth for qo/531A4FB7 to 3064 kbps
03/17 01:06:27 Info: FTMSI-B-OE qo/531A4FB7 rid:1 response took 153ms
03/17 01:06:27 Debug: FTMSI-B-OE qo/531A4FB7 rid:1 request ended – first block: 0 blocks read: 0 download speed: -256kbps response time: 153ms
03/17 01:06:27 Debug: FTMSI-B-OE qo/531A4FB7 rid:1 request ended – first block: 0 blocks read: 0 download speed: -256kbps response time: 153ms
03/17 01:06:27 Debug: FTMSI-B-OE qo/531A4FB7 interrupted req 1; missing block 0

03/17 01:06:27 Debug: FTMSI-B-OE qo/531A4FB7 created new req 2 for block 0 p 0; active requests 1
03/17 01:06:27 Debug: [easyhttp] [8703] GET to https://streaming-qobuz-std.akamaized.net/file?uid=3089804&eid=342289702&fmt=7&profile=raw&app_id=188245549&cid=2202808&etsp=1773731187&hmac=oq4BiRTBSx4zTCnP27xnUd-pqMg returned a
fter 116 ms, status code: 200, request body size: 0 B
03/17 01:06:27 Debug: FTMSI-B got length for qo/531A4FB7; 57.4 MBytes
03/17 01:06:27 Debug: FTMSI-B-OE set min bandwidth for qo/531A4FB7 to 3064 kbps
03/17 01:06:27 Info: FTMSI-B-OE qo/531A4FB7 rid:2 response took 116ms
03/17 01:06:27 Debug: FTMSI-B-OE qo/531A4FB7 rid:2 request ended – first block: 0 blocks read: 0 download speed: -256kbps response time: 116ms
03/17 01:06:27 Debug: FTMSI-B-OE qo/531A4FB7 interrupted req 2; missing block 0

My temporary workaround is to check end point devices that look like they’re playing music (although no music is heard) and stopping them. If that doesn’t work, restart the Roon Appliance.

mjw · March 18, 2026, 9:10am

Have you checked your firewall logs to see if it is blocking the content delivery network? Whilst Roon uses Cloudflare, Qobuz uses Akamai.

Incidentally, HTTP 200 means OK, and the message means zero content. This may indicate that the request was intercepted by your network security.

vadim · March 18, 2026, 12:33pm

Hello @Dadoo

First off, I have to commend your troubleshooting skills! That is some excellent log parsing, and having a Grafana dashboard monitoring Qobuz download speeds is a fantastic setup.

You have perfectly isolated the behavior. The FTMSI-B process in Roon is doing exactly what it’s supposed to do by retrying the fetch, but it’s hitting a strange wall. As mjw rightly pointed out, receiving an HTTP 200 (Success) status code but with an absolutely empty payload (first block: 0 blocks read: 0) is a classic hallmark of a network intercept. Roon is successfully shaking hands with a server, but it’s not the actual Akamai CDN node handing over the audio file—it is almost certainly a network security layer returning a blank response.

Since this isn’t a software bug within Roon itself, but rather an environmental routing or filtering block, here are the two most likely culprits and how to test them:

Firewalla Interception

Firewalla routers are incredibly robust, but features like Active Protect, Ad Block, or strict filtering rules can sometimes aggressively intercept CDN traffic (like Akamai, which Qobuz relies on).

Check your Firewalla logs around the exact timestamps of these loops to see if any Akamai URLs are being flagged or sinkholed. Try temporarily putting the Roon Server in an unfiltered group or pausing the strict rules to see if the track downloads successfully.

DNS Routing

Sometimes, your ISP’s default DNS resolves the Qobuz/Akamai URL to a stale, unresponsive, or filtered regional node.

Try changing the DNS servers on your Firewalla router (or directly on the Roon Server host machine) to a reliable public DNS like Cloudflare (1.1.1.1 and 1.0.0.1) or Google (8.8.8.8 and 8.8.4.4). This often forces the network to map a new, healthy route to the content delivery network.

Felipe_Williams · March 18, 2026, 1:16pm

Hi @vadim
I was going to open a ticket. I have this same exact behaviour since a couple of days. I can share my detailed logs too.
I can see similar other tickets creater with loops during streaming.
The problems are not IP related as qobuz app works perfectly, it’s roon using this endpoint (it seems qobuz app uses a different one). https://streaming-qobuz-std.akamaized.net

Please advise, thanks
Felipe

Dadoo · March 18, 2026, 9:46pm

@mjw thanks for the pointer to Firewalla. Unfortunately I missed an opportunity to check its logs because the time range is limited to 24 hours. Will keep an eye on both Roon and FIrewalla logs when this situation occurs again. Edit (2026-03-19): Saw this issue again tonight and checked Firewalla logs in time and there was nothing indicating it was modifying packets, changing headers, blocking downloads, or redirecting traffic.

Qobuz’s CDN (Akamai) looks like it’s configured to cache requests for 24 hours (see max-age=86400 below):

curl -sI https://streaming-qobuz-std.akamaized.net/file?uid=3089804&eid=241307631&fmt=7&profile=raw&app_id=188245549&cid=2202808&etsp=1773870661&hmac=KOWBQF4Fea3qPnoSKvciL2d9SAk

HTTP/1.1 200 OK
Content-Type: audio/flac
Content-Length: 53763247
ETag: 7U14FbR2ZzF58wULZNtAqw==
Server: nginx
Accept-Ranges: bytes
Cache-Control: public, max-age=86400
X-Amz-Cf-Pop: FRA56-P13
X-Amz-Cf-Id: EGGjcxU_d_0E_cwZkrMDxIYA52T-haRC6YjWF4KAl3MkzA6er4RpNw==
Date: Wed, 18 Mar 2026 21:03:50 GMT
Connection: keep-alive
Akamai-Request-BC: [a=23.45.126.44,b=3733172227,c=g,n=US_IL_MOUNTPROSPECT,o=20940]
Akamai-Mon-Iucid-Del: 1155635
X-Forward-Proto: http
CDN-Origin-Protocol: HTTP

For this issue, an HTTP 200 status was returned by Akamai’s edge server, but maybe the content-length was 0 bytes and if so, would have stayed that way until the cache expired.

Dadoo · March 18, 2026, 9:46pm

@vadim regardless of CDN caching, firewall blocking, and so on, it’s worth noting that the Roon server attempts to download music files from Qubuz’s CDN repeatedly without throttling or timeout.

Please let us know if there is retry logic with backoff similar to the way RAAT Server attempts to connect with Roon remotes (see below) with a final status indicating download failed, so Roon remotes can update their interface and show playback has stopped. If not, I appreciate your guidance on the practicality of reporting this as a feature request or enhancement to existing server functionality.

11:23:33 Trace: [raatserver] [RaatServer iPhone @ 192.168.114.107:9200] lost client connection. Retrying(0)

11:23:33 Trace: [raatserver] [RaatServer iPhone @ 192.168.114.107:9200] client connection failed. Retrying in 500ms

11:23:34 Trace: [raatserver] [RaatServer iPhone @ 192.168.114.107:9200] client connection failed. Retrying in 750ms

11:23:35 Trace: [raatserver] [RaatServer iPhone @ 192.168.114.107:9200] client connection failed. Retrying in 1125ms

11:23:36 Trace: [raatserver] [RaatServer iPhone @ 192.168.114.107:9200] client connection failed. Retrying in 1687ms

I took a look at 3 DNS queries and they are pointing to the same IP address for Akamai’s edge server.

Default DNS

dig +short streaming-qobuz-std.akamaized.net
splitter.streaming-qobuz-std.akadns.net
streaming-qobuz-std-edge.akamaized.net
a1094.dscv.akamai.net
23.211.176.22
23.211.176.44

Cloudflare DNS

dig +short @1.1.1.1 streaming-qobuz-std.akamaized.net
splitter.streaming-qobuz-std.akadns.net
streaming-qobuz-std-edge.akamaized.net
a1094.dscv.akamai.net
23.211.176.44
23.211.176.22

Google DNS

dig +short @8.8.8.8 streaming-qobuz-std.akamaized.net
splitter.streaming-qobuz-std.akadns.net
streaming-qobuz-std-edge.akamaized.net
a1094.dscv.akamai.net
23.211.176.44
23.211.176.22

vadim · March 19, 2026, 5:43pm

Hello @Dadoo

We’ve discussed this with our senior QA and development teams. The team is investigating some possibilities here and, as soon as that investigation is complete, we’ll be sure to follow up ASAP.

You have our apologies for the trouble here, and we’ve greatly appreciated your patience as we continue investigating this tricky issue. We’ll be in touch as soon as we can.

Dadoo · March 20, 2026, 9:22pm

There are issues with Qobuz, but Roon should guard against the situation.

I continue to experience Roon remotes suddenly stopping music playback:

Music stops midway through a song
Music player UI show play button enabled but the progress indicator between time played and time remaining moves back and forth
Clicking the skip/next button will start music playback with the next track in the album

However, there are a couple issues:

Roon server continues to make millisecond requests for the “stuck” music file in the background
Qobuz’s tiered distribution gateways are failing - perhaps intentionally

I saw this happening while sitting in front of the Roon remote, and did some sleuthing.

curl -H “Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no” -IXGET https://streaming-qobuz-std.akamaized.net/…

At the top of the response from Akamai we see that a) the request was successfully processed, b) Qobuz’s FLAC file is cached, c) the file length is 61756911 bytes, and d) there was a matching file found in their cache (TCP_HIT).

HTTP/1.1 200 OK
Content-Type: audio/flac
Cache-Control: public, max-age=86400
Content-Length: 61756911
X-Cache: TCP_HIT from a23-215-178-135.deploy.akamaitechnologies.com (AkamaiGHost/22.4.4-cf5672731e69c345796af56199edfb50) (-)

Issue #1: Roon server continues to download music file without rate limiting

The actual response from Akamai is just a 1 byte payload
For one stuck song, Roon server attempted to get the complete file 8982 times for 44 minutes
With my internet connection that averages out to one request every 294 milliseconds

Issue #2: Qobuz distribution servers are failing to deliver source file

The following is a continuation of the output from the curl command above. Note the following:

ERR_DNS_TIMEOUT
Status codes are: 500, 502, 504

X-Akamai-Session-Info: name=TD_IMPL_ORIGIN_LOCATION; value=europe
X-Akamai-Session-Info: name=TD_IMPL_PARENT_MAP_0; value=a378.cheu2p.akamai.net
X-Akamai-Session-Info: name=TD_IMPL_PARENT_MAP_0_ALT; value=a378.cheu2f.akamai.net
X-Akamai-Session-Info: name=TD_IMPL_PARENT_MAP_0_ALT_ERROR_CODES; value=ERR_DNS_IN_REGION ERR_DNS_TIMEOUT
X-Akamai-Session-Info: name=TD_IMPL_PARENT_MAP_0_ALT_STATUS_CODES; value=500 502 504
X-Akamai-Session-Info: name=TD_IMPL_POLICY; value=tiered-distribution
X-Akamai-Session-Info: name=TD_IMPL_SERIAL; value=378
X-Akamai-Session-Info: name=TD_IMPL_T0_KEY; value=europe
X-Akamai-Session-Info: name=TIER0_ALT_MAP; value=a853.cheu2f.akamai.net
X-Akamai-Session-Info: name=TIER0_MAP; value=a853.cheu2.akamai.net
X-Akamai-Session-Info: name=TIER1_SRO_SERIAL; value=2834

Tomi_Blinnikka · March 21, 2026, 3:09am

I’ve had this same issue for a while, too (at least exactly the same symptoms).

I wouldn’t be surprised if the uncontrolled retry logic in Roon is causing users to get blacklisted by the CDN.

mjw · March 21, 2026, 8:56am

Unlikely, given the 200 response from the server. A 4xx code, e.g., 427, would most likely be returned.

Dadoo · March 22, 2026, 10:24pm

@Tomi_Blinnikka, Akamai limits the retries based on my review of one stuck song (failed file download). So no blacklisting taking place. Here’s what I saw in the logs and Akamai.

Relevant lines from the Roon server logs

03/22 15:45:45 Info: FTMSI-B new FileCache qo/E3BE7969

File request #1 got an HTTP 200 from Akamai

03/22 16:00:41 Warn: FTMSI-B qo/E3BE7969: block downloader too much time locked

Interesting that Roon server knows there’s a problem with the file download

03/22 16:46:06 Warn: FTMSI-B-OE qo/E3BE7969 rid:1298 error response: 410

File request #1298 got an HTTP 410 from Akamai

Manual verification using curl

HTTP/1.1 410 Gone
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 404
Expires: Sun, 22 Mar 2026 21:52:34 GMT
Date: Sun, 22 Mar 2026 21:52:34 GMT
X-Cache: TCP_DENIED from a23-33-86-31.deploy.akamaitechnologies.com (AkamaiGHost/22.4.4-cf5672731e69c345796af56199edfb50) (-)

Dadoo · March 23, 2026, 5:31am

Quick update: I think I’m incorrectly interpreting those ERROR_CODES and STATUS_CODES from the X-Akamai-Session-Info headers: they look more like static configuration settings and not dynamic values. This is based on a couple things…

I was able to download a “stuck” file from Qobuz’s staging edge server while their prod environment was failing to serve the file. Yet the ERR_DNS_TIMEOUT and 500 502 504 in the headers from the staging server are the same as prod.
Akamai docs seem to indicate status codes are configured by the customer (Qobuz) and they are separated by spaces

vadim · March 25, 2026, 11:26am

Hello @Dadoo,

Thank you for the update

At this stage, we have gathered enough diagnostic data and logs from users experiencing similar symptoms to move forward. Our engineering team is already working on optimizing the interaction with the Qobuz CDN to ensure Roon can gracefully handle these “empty” server responses (HTTP 200 with no data) and avoid infinite retry loops.

No further logs or tests are needed from your side. The best way to track our progress is to keep an eye on our Roon Software Discussion > Software Release Notes , where we announce all streaming stability fixes.

Thank you for your patience while we work on the resolution. Would you like me to keep this thread open in the meantime?

Dadoo · March 25, 2026, 11:56am

Thanks for the follow-up @vadim

I’ve marked your reply as the solution, so go ahead and close the issue. I’ll follow the release category for updates.

system · March 26, 2026, 11:57am

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.