Environment Roon Server Version: Roon 2.67 (Build 1661) Operating Systems Tested GentooPlayer x86 (Embedded Roon Server) Windows 11 (Standalone Roon Server)
The issue occurs on both systems.
Streaming Service
Qobuz
Network Environment
ISP:
BIGLOBE (Japan)
Connection:
IPv6 IPoE (v6 Plus)
Router:
Buffalo WSR-3000AX4P
MTU:
Router: 1500 Windows Ethernet: 1500 Issue Description
After signing into Qobuz, Roon initially works correctly.
After some time (or immediately after Qobuz library synchronization begins), the following symptoms occur:
Metadata Improver becomes "Paused" Album metadata disappears Playback stops unexpectedly Qobuz pages fail to load Roon Radio becomes unavailable Discover, New Releases and Genres return:
"Page loading error" "Please check your network connection."
The issue is temporarily resolved by:
Restarting Roon Server Signing out and back into Qobuz
However, the problem eventually returns.
Reproduction Steps Start Roon Server. Sign into Qobuz. Automatic Qobuz library synchronization starts. Open: Discover New Releases Genres Roon Radio
Result:
Most requests eventually fail.
If synchronization is still running, the failure occurs almost immediately.
Even after synchronization completes, the first request often fails.
Waiting several minutes sometimes allows pages to open again.
which confirms successful TLS negotiation and API reachability.
System Resources
Memory:
16 GB RAM
Available memory:
Approximately 14 GB free.
Database size:
144 MB
Disk usage:
Approximately 10%
No memory pressure or storage issues were observed.
Additional Observations
If Qobuz is signed out:
Roon Radio works normally. Navigation is responsive. No page loading errors occur.
The issue only appears after signing into Qobuz.
Cross-platform Verification
The issue occurs on:
GentooPlayer Windows 11
The same behavior is reproduced on both systems.
The issue was also reproduced while using smartphone tethering, indicating it is unlikely to be caused by the ISP, router, or local network.
Suspected Cause
Based on extensive testing, this does not appear to be:
DNS failure IPv4 connectivity IPv6 connectivity MTU configuration Local firewall Router configuration Operating system Hardware performance
The evidence suggests a problem related to:
Qobuz synchronization Metadata API requests Metadata translation service Session or metadata request handling inside Roon after Qobuz login
The failures consistently begin after Qobuz synchronization starts and involve repeated Metadata API timeouts.
Request
Could the development team please investigate:
Qobuz synchronization handling in Build 1661. Metadata API timeout behavior after Qobuz login. Handling of repeated requests to: metadata/1/tracks/translate metadata/1/albums metadata/1/credits Whether there are known issues related to Qobuz API changes affecting Metadata Improver or page loading.
Thank you very much for your assistance.
Tell us about your home network
· This has already been included in the shipping information.
Thank you for this exceptionally thorough report - the cross-platform reproduction, the log excerpts, and the network verification you’ve already done make this much easier to investigate.
We have activated diagnostic mode on your account, so there’s no need to upload anything manually. The next time the issue occurs, please just note the exact date and local time and share it with us here - that will let us match the events against the diagnostics on our side.
One question in the meantime: have you tried reproducing the issue while running the Roon Server machine’s traffic through a VPN? Since your connection uses v6 Plus (IPv4 over IPv6), a VPN test would take the ISP’s translation layer out of the equation - if the problem disappears over VPN, that tells us the network path is involved rather than Roon’s request handling itself.
Once we have fresh timestamps, we’ll review the diagnostics and take it from there. Thank you for your patience!
I am reporting the results verified via VPN.
WARP enabled: No errors observed during the initial test. Discover, New Releases, Genres, and Roon Radio all loaded quickly and normally.
After disabling WARP, the same pages still loaded successfully, although they were slightly slower. Since the pages had already been accessed while WARP was enabled, I suspect the results may have been served from Roon’s cache.
I will continue testing with longer sessions after restarting Roon Server to eliminate any cache effects and will report whether the issue reappears.
An issue has occurred; here is the time it happened:
07/07 14:36:12 Warn: [broker/images] unexpected error
This occurred while repeatedly opening various albums from the Qobuz new releases section.
The albums would no longer open, and albums added via Qobuz disappeared from “My Library.”
Thank you for the timestamp - we’ll pull the diagnostics around 07/07 14:36 (JST) and review what was happening on the connection at that moment.
One crucial detail to interpret the results correctly: at the time this occurred, was WARP enabled or disabled? And had you restarted Roon Server before this session, as you planned? Knowing whether this failure happened on the plain v6 Plus connection or through the VPN tunnel will determine where we look next - if it occurred without WARP after a fresh start, that strengthens the network-path theory; if it occurred with WARP active, we’ll focus on the request handling side instead.
Thank you again for the methodical testing - this is exactly the data we need.
The diagnostic information from around 14:36 on July 7th was obtained while using an IPv6 Plus connection with WARP disabled.
Before performing the check, I stopped the Roon server, cleared the cache, and then restarted the server.
Subsequently, I enabled WARP and tested the connection via the VPN tunnel; so far, the issue has not occurred.
I will continue using it to verify that the problem does not arise and will report back.
Thank you for the timestamp and for confirming the WARP/no-WARP conditions so precisely, that combination of tests has been extremely useful.
We pulled the diagnostics from around 07/07 14:36 JST and cross-referenced them against your local logs. A clear pattern emerged that we wanted to share with you.
During Qobuz library sync, Roon Server issues a large number of parallel requests to fetch album art and metadata. In your diagnostics, we can see these requests behaving very inconsistently - some complete in under 150ms, while others to the exact same host take 15-21 seconds before timing out, often within the same one-second window. This is not a pattern we’d expect from a dead server or blocked endpoint (that would fail uniformly and quickly); it looks like connection/session queuing under load.
This lines up with a known characteristic of IPv6 IPoE (v6 Plus/MAP-E) connections like yours: the CPE and ISP-side border router allocate each subscriber a limited pool of NAT ports/sessions - often a few hundred, versus the much larger pool available on a native public IPv4 connection. A burst of concurrent short-lived HTTPS connections, like the ones Qobuz sync generates, can exhaust that pool. Some connections get through immediately, others queue for a port and eventually time out. This would also explain why your single-request tools (ping, curl, nslookup) never showed a problem, they only ever use one connection at a time and wouldn’t hit that ceiling.
It’s also consistent with what you found on your own: WARP resolves it because it tunnels all traffic through a single multiplexed connection rather than opening many independent sessions through your ISP’s MAP-E gateway, sidestepping the session limit rather than fixing anything on Roon’s side.
In your logs, the timeouts cluster tightly around the sync period and clear up once sync finishes and request volume drops, which matches your report that waiting it out sometimes lets pages load again.
In the meantime, a couple of things worth checking on your end:
If your router or BIGLOBE’s v6 Plus service exposes any setting for NAT session/port table size, increasing it may raise the threshold before this occurs.
Since WARP reliably avoids the issue, keeping it enabled is currently the most dependable workaround.
Thank you for analyzing the logs.
I understand now that the issue is caused by connection limitations associated with IPv6 IPoE (v6 Plus/MAP-E).
Unfortunately, the router model I am using (BUFFALO) does not allow for the modification of NAT table settings or MAP-E session limits that you suggested.
Since the number of MAP-E sessions assigned by BIGLOBE cannot be changed by the user either, I will consider using a VPN connection, such as WARP.
Glad WARP gets you a reliable path around this. To sum up: the root cause is the limited NAT session pool on IPv6 IPoE (v6 Plus/MAP-E) connections, which the burst of parallel requests during Qobuz sync can exhaust. Since neither your router nor BIGLOBE exposes a way to raise that limit, keeping WARP enabled during sync is the most dependable fix available on your end.
Thank you for the exceptionally thorough testing throughout this, the cross-platform checks, timestamps, and WARP/no-WARP comparisons made this straightforward to pin down.