What kind of performance/speed issue are you experiencing?
· The app takes a long time to respond to commands
Please try to reboot your Roon Server
· No, the issue is still the same even immediately after a reboot
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?
· MacOS
Timestamp of issue occurrences
· 01/31 21:09:22
Describe the issue
I'm getting a lot of timeouts from when searching and browsing artists and albums. I've changed DNS from providers to google/cloudflare, dis-/enabled ipv6, rebooted router, switches, macbook w/ roon server and ipads.
01/31 21:31:45 Debug: [easyhttp] [12496] GET to https://api.roonlabs.net/discover/1/performers/94:1:a2e7d9e7-f675-431a-802a-2778e1462964/albums/recommended?profile=<...>&c=qobuz-de&contentPreferences=preferQobuz,reallyAvoidMqa&tidal=max timed out after 60023 ms
01/31 21:31:45 Debug: [easyhttp] [12507] GET to https://api.roonlabs.net/discover/1/performers/94:1:a2e7d9e7-f675-431a-802a-2778e1462964/performers/alsofrom?profile=<...>&c=qobuz-de&textSources=Wikipedia:en,Rovi-compositions:en,Rovi-artists:en,Wikipedia:de,Rovi-albums:en&tidal=max timed out after 60022 ms
01/31 20:46:01 Warn: [broker/images] unexpected error GET'ing https://imagecache.roonlabs.net/im/1/albums/c80030303735353937393436343638/cover/512.jpg: statuscode=998 error=Request canceled due to timeout
01/31 20:46:01 Trace: GetImageData[Remote](id=34587 spec=512 key=hezbaaaa uri=https://imagecache.roonlabs.net/im/1/albums/c80030303735353937393436343638/cover/512.jpg) => fetched in 100024ms status=998 size=0 overalltime=10002
6ms
I had to relog into my account with roon server today and it works a little better. Still artists and albums randomly get stuck in loading/timeouts, one or two reload attempts are needed to display them. Streaming Qobuz works fine.
Thank you for the detailed logs — they’re very helpful.
To fully rule out any ISP- or routing-level interference and continue troubleshooting, we’d like to ask you to run one additional test:
Please try temporarily enabling a VPN on the Mac running Roon Server (any reputable VPN provider is fine) and then test:
Browsing artists
Loading album pages
Search responsiveness
If metadata and images load reliably while connected through the VPN, this would strongly indicate that the issue is related to routing or filtering between your ISP and Roon’s cloud services, rather than the Roon application itself.
Once you’ve tested:
Let us know whether the behavior improves with the VPN enabled
You can then disable the VPN again — this is only a diagnostic step
Thanks again for your patience. Once we have this result, we’ll be able to advise on the most appropriate next steps.
May I join this thread with the same issue, or should I start a new one?
The background is that I am experiencing similar problems, am also a Deutsche Telekom customer (the only ISP available to me at my location, I can’t switch), and have confirmation that the problems will be resolved by using a VPN. I also have a statement from Telekom that says the following:
It is clearly a peering problem.
Unfortunately, we have no control over how Cloudflare routes traffic. However, you can use a VPN to bypass this. <<<
My question here @vadim:
Are the problems actually related to Cloudflare, or rather to the costs that Deutsche Telekom would demand from Cloudflare for a direct interconnection and use of its networks, which Cloudflare in turn would demand from Roon Labs, and which Roon Labs is unwilling to pay? And instead, data traffic is routed through transit providers that are overloaded, especially in the evenings, leading to slow connections, high pings, and packet loss, sometimes resulting in total unusability.
I checked cloudflare routes, currently 2 IPs are resolved for api.roonlabs.net
api.roonlabs.net. 14 IN CNAME api.roonlabs.net.cdn.cloudflare.net.
api.roonlabs.net.cdn.cloudflare.net. 14 IN A 172.66.148.147
api.roonlabs.net.cdn.cloudflare.net. 14 IN A 104.20.47.62
I’ve got a some packetloss on 104.20.47.62
64 bytes from 104.20.47.62: icmp_seq=176 ttl=56 time=10.566 ms
64 bytes from 104.20.47.62: icmp_seq=177 ttl=56 time=10.803 ms
64 bytes from 104.20.47.62: icmp_seq=178 ttl=56 time=10.599 ms
Request timeout for icmp_seq 179
Request timeout for icmp_seq 180
64 bytes from 104.20.47.62: icmp_seq=181 ttl=56 time=10.692 ms
64 bytes from 104.20.47.62: icmp_seq=182 ttl=56 time=10.837 ms
64 bytes from 104.20.47.62: icmp_seq=183 ttl=56 time=10.593 ms
64 bytes from 104.20.47.62: icmp_seq=184 ttl=56 time=10.668 ms
Request timeout for icmp_seq 185
64 bytes from 104.20.47.62: icmp_seq=186 ttl=56 time=10.547 ms
Request timeout for icmp_seq 187
64 bytes from 104.20.47.62: icmp_seq=188 ttl=56 time=10.826 ms
64 bytes from 104.20.47.62: icmp_seq=189 ttl=56 time=10.845 ms
> $ traceroute 172.66.148.147
traceroute to 172.66.148.147 (172.66.148.147), 64 hops max, 52 byte packets
1 fritz.box (192.168.178.1) 1.339 ms 0.794 ms 0.816 ms
2 xxx.dip0.t-ipconnect.de (xxx) 2.608 ms 3.097 ms 2.200 ms
3 ams-sb5-i.ams.nl.net.dtag.de (217.239.60.105) 19.140 ms 21.720 ms 19.085 ms
4 adm-b3-link.ip.twelve99.net (62.115.191.142) 19.233 ms 19.002 ms 18.817 ms
5 adm-bb1-link.ip.twelve99.net (62.115.136.220) 117.676 ms
adm-bb2-link.ip.twelve99.net (62.115.138.170) 75.394 ms
adm-bb1-link.ip.twelve99.net (62.115.136.220) 117.876 ms
6 adm-b10-link.ip.twelve99.net (62.115.138.251) 116.591 ms
adm-b10-link.ip.twelve99.net (62.115.138.37) 106.841 ms
adm-b10-link.ip.twelve99.net (62.115.138.251) 117.484 ms
7 cloudflare-ic-342028.ip.twelve99-cust.net (62.115.172.231) 29.062 ms 29.735 ms 40.959 ms
8 141.101.65.139 (141.101.65.139) 38.379 ms
141.101.65.99 (141.101.65.99) 39.723 ms
141.101.65.115 (141.101.65.115) 31.978 ms
9 172.66.148.147 (172.66.148.147) 29.027 ms 28.881 ms 28.956 ms
and
> $ traceroute 104.20.47.62
traceroute to 104.20.47.62 (104.20.47.62), 64 hops max, 52 byte packets
1 fritz.box (192.168.178.1) 1.146 ms 0.837 ms 0.844 ms
2 xxx.dip0.t-ipconnect.de (xxx) 2.917 ms 2.215 ms 2.426 ms
3 f-ed14-i.f.de.net.dtag.de (217.5.67.10) 11.259 ms 10.938 ms 11.127 ms
4 193.251.143.89 (193.251.143.89) 10.922 ms 10.838 ms *
5 193.251.133.158 (193.251.133.158) 15.646 ms 14.998 ms 17.770 ms
6 193.251.150.138 (193.251.150.138) 23.596 ms
193.251.150.208 (193.251.150.208) 25.237 ms 11.407 ms
7 162.158.84.79 (162.158.84.79) 11.209 ms
162.158.84.78 (162.158.84.78) 10.882 ms
162.158.84.79 (162.158.84.79) 11.276 ms
8 162.158.84.221 (162.158.84.221) 14.287 ms
162.158.84.27 (162.158.84.27) 18.335 ms
162.158.84.241 (162.158.84.241) 11.764 ms
9 104.20.47.62 (104.20.47.62) 11.791 ms 11.917 ms *
Thanks for the input @Axel_Lesch. With the dirty hack to put 172.66.148.147 in /etc/hosts for api.roonlabs.net on my roon server i had no problems at all. Definitely a problem with one of the routes from Cloudflare.
It’s a complex issue for which Telekom denies all responsibility.
However, it’s clear that you don’t have this problem with Vodafone and O2, who apparently manage to reach an agreement with Cloudflare.
If you are interested in the topic, here is something ..
Here’s a statement from Telekom regarding the recent changes from about two weeks ago.
“Cloudflare has independently changed its decisions regarding the transfer of traffic to our network in recent days. We have no control over the routes Cloudflare uses to route its data into our network. Telekom is not experiencing any service disruptions.”
Thank you for the detailed analysis and for sharing the traceroutes and packet-loss testing — this is very helpful.
To clarify a few important points:
Roon uses Cloudflare as a CDN and edge network to serve metadata, images, and API traffic (such as api.roonlabs.net and imagecache.roonlabs.net). We do not control how individual ISPs and Cloudflare select routes between each other, nor can we influence which specific Cloudflare edge IP a given client is routed to at any moment.
What your testing clearly shows is:
One Cloudflare edge IP (104.20.47.62) is experiencing intermittent packet loss from Deutsche Telekom
Another Cloudflare edge IP (172.66.148.147) is stable
Routing through a VPN (or forcing the stable IP) avoids the issue entirely
This strongly indicates a routing / peering issue between Deutsche Telekom and part of Cloudflare’s network, not a problem within the Roon application itself.
Regarding your question about costs or commercial agreements:
We’re not able to comment on peering arrangements, financial negotiations, or ISP-to-CDN policies. From Roon’s perspective, Cloudflare is functioning as designed, and routing decisions are made dynamically between Cloudflare and the ISP.
At this time, the practical workarounds are:
Using a VPN on the Roon Server
Waiting for routing to normalize on Telekom / Cloudflare paths
Continuing to report the issue to Telekom and/or Cloudflare with the traceroute and packet-loss evidence you’ve already collected
We appreciate the level of investigation you’ve done here — it aligns exactly with what we’d expect to see when routing instability is the root cause.
Please let us know if anything changes on your side, or if the behavior persists even when routing conditions improve.
We wanted to reach out to affected users to inquire if there had been any improvement in the last three days. If you have the capacity, please also test whether changing the network path by activating a consumer VPN still resolves the issue.
I’ve been using wireguard on a friends’ server to bypass telekom/cloudflare pathsn since wednesday. Works like a charm. But since you asked i just deactivated VPN and will try without it for a while. A first test with browsing a few albums and doing a few searches didn’t show any timeouts. If i should try out something specific, e.g. traceroute or mtr, please feel free to ask.