Roon Discovery API timeouts (ref#HIIWL8)

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Subject: Roon Discovery API timeouts – Recommended Albums / Similar Artists / New Releases take 60 seconds to load
Hello Roon Support,
I am experiencing a persistent problem with the Discovery sections on Artist pages in Roon.
The upper part of the Artist page loads normally and my local library browsing is fast. However, the Discovery sections such as Recommended Albums, New Releases, Similar Artists, Also From and Collaborations are extremely slow.
The problem occurs consistently and also affects multiple Roon Remotes, so it is not specific to a single client.
Roon Server
• Roon version: 2.71 build 1683 (Production)
• Server: Synology DS1525+
• Roon Server runs in Synology Container Manager / Docker
• RAM: 16 GB
• Music library: approximately 99,099 tracks / 7,227 albums / 2,999 artists
• IPv6: disabled
• CPU and RAM usage are normal
Exact Discovery API failures
The Roon Server log shows the following requests timing out:
09/05 21:22:47 Debug: [easyhttp] [8319] GET to https://api.roonlabs.net/discover/1/performers/122:0:MN0000126529/albums/recommended?... timed out after 59999 ms

09/05 21:22:47 Debug: [easyhttp] [8325] GET to https://api.roonlabs.net/discover/1/performers/122:0:MN0000126529/albums/new?... timed out after 60000 ms

09/05 21:22:47 Debug: [easyhttp] [8324] GET to https://api.roonlabs.net/discover/1/performers/122:0:MN0000126529/performers/similar?... timed out after 60000 ms

09/05 21:22:47 Debug: [easyhttp] [8330] GET to https://api.roonlabs.net/discover/1/performers/122:0:MN0000126529/performers/alsofrom?... timed out after 60000 ms
There is also a collaboration request which took over 50 seconds before returning 404:
09/05 21:22:38 Debug: [easyhttp] [8322] GET to https://api.roonlabs.net/discover/1/performers/122:0:MN0000126529/featured/collaboration?... returned after 50656 ms, status code: 404
These delays correspond directly to the sections that are slow on the Artist page.
Local Roon Server appears healthy
The Roon Server itself does not appear to be overloaded.
For example, at the same time:
Physical memory: ~4974 MB
GC pauses: very low
query_rebuilds: 0
Local library queries and normal album/artist browsing remain responsive.
Network test
I also tested connectivity from inside the Roon container.
discover.roonlabs.net resolves to:
35.231.208.158
A direct HTTPS connection to this address is fast:
connect=0.122893
tls=0.259681
total=0.382650
code=404
So basic TCP/TLS connectivity to the Discovery server is working normally. The problem appears to occur specifically when Roon performs the authenticated Discovery API requests.
I have also already tried restarting the Roon Server/container and the problem persists.
What I would like you to investigate
Could you please check whether there is currently a problem with the Roon Discovery/Valence backend for these endpoints, particularly:
• /performers/.../albums/recommended
• /performers/.../albums/new
• /performers/.../performers/similar
• /performers/.../performers/alsofrom
• /performers/.../featured/collaboration
The fact that several different Discovery endpoints consistently hit almost exactly the 60-second timeout makes me suspect a problem with the Discovery backend or the processing/cache layer rather than my local Roon Server.
I can provide the complete Roon Server logs and any additional diagnostic information you need.
Thank you.

Tell us about your home network

· Cloud gateway max

I performed a controlled reproduction and inspected the RoonServer logs on my Roon server. The results consistently show endpoint-specific 60-second Discovery API timeouts.

Environment

  • Roon: 2.71 build 1683, Production
  • Official Roon Docker image: 1.0.8
  • Host: Unraid 7.3.2
  • Docker: 29.5.3
  • CPU: Intel Core i3-1315U
  • RAM: 15 GiB
  • RoonServer state during testing: healthy
  • Automatic restarts: 0
  • OOM events: none
  • Remote: MacBook Pro on the same LAN; Tailscale was enabled
  • My Roon server’s cloud traffic used its active Ethernet interface, not Tailscale

All times below are Europe/Amsterdam time on 2026-09-06.

Controlled reproduction

Shaboozey — 11:32

The artist page showed a loading spinner for about 60 seconds. Only Influences loaded afterward.

  11:33:41 GET /discover/1/albums/121:0:MW0004803034/performers/similar
  timed out after 59999 ms
  NetworkTimeout (HTTP 998)

  11:33:43 GET /discover/1/performers/122:0:MN0003690780/performers/similar
  timed out after 60000 ms
  NetworkTimeout (HTTP 998)

Phoebe Bridgers — 11:36

The page loaded for about 60 seconds. Upcoming concerts and followers/collaborators loaded.

  11:36:50 GET /discover/1/albums/121:0:MW0003375607/performers/similar
  timed out after 59999 ms
  NetworkTimeout (HTTP 998)

  11:37:02 GET /discover/1/performers/122:0:MN0003207984/performers/similar
  timed out after 60000 ms
  NetworkTimeout (HTTP 998)

Death Cab for Cutie — 11:39

The page loaded for about 60 seconds. Upcoming concerts, Influences, followers, and associated-with information loaded.

  11:40:05 GET /discover/1/albums/121:0:MW0000319183/performers/similar
  timed out after 60000 ms
  NetworkTimeout (HTTP 998)

  11:40:10 GET /discover/1/performers/122:0:MN0000812711/performers/similar
  timed out after 60000 ms
  NetworkTimeout (HTTP 998)

Phoebe Bridgers repeated — 11:41

Reopening the same artist produced the same spinner and delay, so no successful cached result was used.

  11:42:06 GET /discover/1/albums/121:0:MW0003375607/performers/similar
  timed out after 59999 ms
  NetworkTimeout (HTTP 998)

  11:42:07 GET /discover/1/performers/122:0:MN0003207984/performers/similar
  timed out after 59999 ms
  NetworkTimeout (HTTP 998)

In total, the test produced eight separate timeouts of exactly 59,999–60,000 ms across three artists and one repeated artist.

Other Roon cloud calls remained fast

During the same test windows, other authenticated calls to api.roonlabs.net completed normally:

  • Metadata and biography: 77–386 ms
  • performers/top: 175–298 ms, HTTP 200
  • Concert data: 183–1,385 ms, HTTP 200
  • Daily picks: 155–349 ms, HTTP 200
  • Device-map registration: 290–664 ms, HTTP 200

The failures therefore appear specific to:

  /discover/1/albums/.../performers/similar
  /discover/1/performers/.../performers/similar

Historical logs from the same RoonServer show these endpoints previously returning HTTP 200 in approximately 303–1,615 ms. One later request took 22,290 ms, followed by the
current consistent 60-second timeouts.

Network validation

I also checked my servers general connectivity:

  • 200 packets to the router: 0% loss
  • 200 packets to 1.1.1.1: 0% loss
  • 200 packets to 8.8.8.8: 0% loss
  • 200 packets to discover.roonlabs.net: 0% loss
  • Full 1,500-byte packet tests: 0% loss
  • Ethernet CRC, frame, carrier, FIFO, and timeout errors: 0
  • Ethernet link failures: 0
  • DNS responses: approximately 1–26 ms
  • Basic DNS/TCP/TLS/HTTP connection to discover.roonlabs.net: approximately 0.34–0.38 seconds

Bump for Roon support, there is something wrong on their servers.

Seems to be ok for me again but I had to reboot the server.

Today is definitely better, although sometimes there is still a 2-3 delay.

When randomly switching between different artists, the refresh time is usually quite fast, but loading the overview still occasionally experiences delays of 10 seconds or longer.

Hello,

We saw the same degradation on our side over the weekend, and it was not limited to your servers. Several other reports came in over the same window with the same shape: requests to the discovery service either timing out at exactly 60 seconds or coming back very slowly, while everything else against the same host stayed fast.

Things improved on the 7th, which matches what you are both seeing now. The team is aware and is working on it.

One thing worth saying to anyone reading later: there is no need to reboot your server for this. A restart that happens to coincide with the service recovering looks like a fix and is not one.

It’s better, but still slow (sub 5 seconds)