· 24/192 Qobuz starves in Roon but plays perfectly via Qobuz Connect to the same endpoint Plus a second, arguably more serious defect: silent failure on endpoints that don’t report dropouts.
Tell us about your home network
· Roon Core Machine Mac mini (Macmini9,1), Apple M1, 8 GB RAM, macOS 26.5.2 (25F84). RoonServer v2.71 build 1679 (earlyaccess), headless under launchd. Library ~34,700 tracks. Timezone CDT (UTC−05:00) — all timestamps local.
Networking Gear & Setup Details UniFi, all wired gigabit Ethernet, no Wi-Fi in the audio path. Core at 10.10.10.10 on en0, 1000baseT full duplex. Measured on the Core immediately around the failures:
Capacity: 884 Mbps down / 807 Mbps up (networkQuality, “High” accuracy, 1.17 GB down / 960 MB up actually transferred) Bufferbloat: idle 16.0 ms → 32.8 ms under full saturation (+16.8 ms), Responsiveness “High” Path to Qobuz: streaming-qobuz-std.akamaized.net resolves to a local Akamai edge — 4 ms RTT, 0% loss, 10 ms TLS connect To the endpoints: 0% loss The failures occur while the link carries only ~3.7 Mbps — about 0.4% of capacity — so there is no congestion or queue pressure to speak of.
I’m trying to create a separate support ticket, but since this may be related, here’s a link to a detailed analysis demonstrating Roon’s inability to sustain the source fetch from Qobuz.
No. It doesn’t matter what endpoint. And it fails the same way if I have Roon downsample before sending to the WiiM. Roon cannot sustain the 192kHz stream. And it struggles with 96kHz as well.
And yet those same files play perfectly over my network to the exact same devices using Qobuz Connect.
Did you read the attached analysis?
Track: X — “We’re Desperate (Live)”, from Wild Gift (2019 Remaster) (Live), Qobuz, 24-bit/192 kHz.
Roon cannot sustain the source fetch for this track. Across 7 attempts it never once reached the required rate:
Warn: FTMSI-B-OE qo/<id>: poor connection kbps:4014.0 (min:5912.0)
Debug: [prebuffer] sleeping in read -- this isn't good
Warn: [WiiM] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
The zone buffer sits at 2% and never recovers; a lower-rate track in the same session shows 100%.
Qobuz hi-res streams killed by prebuffer starvation, and a poor connection figure that tracks its own threshold
Environment
Core: RoonServer on macOS, Apple M1, 8 GB RAM, headless
Version: 2.71 (build 1684), early access channel
Zone: “WiiM + 1”, a grouped zone of a WiiM Ultra and a Naim Mu-so, both wired ethernet
Source: Qobuz
WAN: 900 Mbps bidirectional, measured. Round trip to the Qobuz CDN on getFileUrl: 56 ms
Symptom
Roon kills Qobuz hi-res streams outright. Three in three minutes on one evening:
20:26:31 Warn: [WiiM + Muse] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
20:26:31 Info: [zone ...] OnPlayFeedback StoppedEndOfMediaUnnatural
20:27:38 Warn: [WiiM + Muse] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
20:28:37 Warn: [WiiM + Muse] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
Accompanied by hundreds of [prebuffer] sleeping in read -- this isn't good. It affects 24/96 as well as 24/192. 16/44.1 is unaffected.
A representative kill: Social Distortion, Mommy’s Little Monster, 24/96, advanced 7 seconds of audio in 17 seconds of wall clock and died. DSP was running at 45x to 47x realtime throughout. The Core had the CPU. It did not have the bytes.
The central measurement: delivered rate tracks the requirement
This is the part I would most like explained.
Across one day, 526poor connection warnings. Grouped by each warning’s own min: value, taking the best delivered rate observed in each group:
min: required
warnings
best delivered
short by
2717
1
2708
9
2931
2
2929
2
3033
5
3032
1
3422
50
3420
2
3462
25
3461
1
3543
50
3542
1
3751
18
3746
5
3867
50
3861
6
3901
22
3878
23
Best-case delivery tracks the requirement across the entire range, 2717 to 3901 kbps, and lands just under it every time.
This rules out a fixed bandwidth ceiling. If delivery were capped near 3.5 Mbps, the bottom rows would show it. Instead, at min:3867 the Core pulled 3861 kbps. The rows carrying 50 samples each are not stray maxima.
What it looks like instead is a fetch paced to the stream’s own bitrate: it pulls about as fast as playback consumes, so the observed rate cannot meaningfully exceed the requirement, and any small dip drops it under a threshold derived from that same requirement. On that reading, poor connection fires as a near-certainty on demand-paced content and says little about the network.
I want to be clear about the status of that: the table is measurement, the pacing explanation is a hypothesis. I cannot separate them from these logs. It would need to be known whether the Core ever races ahead to fill prebuffer on a track it is not struggling with.
It does explain the one thing a ceiling could not: why 16/44.1 never warns. Its requirement (around 1079 kbps) is cleared comfortably by whatever paces the fetch.
As I write this, a 24/88.2 stream is warning at kbps:3031 (min:3033) and playing without a single audible fault. That is the whole puzzle in miniature.
Excluded by direct measurement, not by inference
Suspect
The measurement that clears it
WAN capacity
900 Mbps bidirectional, measured
Qobuz CDN latency
getFileUrl HTTPS GET returned in 56 ms
CPU / DSP load
tracks killed while processing at 45x to 53x realtime
Garbage collection
two different days, two different heap states (2,257 MB flat; 3,096 MB committed), same failure. Longest GC pause 382 ms, under 1% of runtime
The endpoints
[zoneplayer/raat] sync ... result: Success runs continuously through the kill window for both, and both are wired
One bad track or stream
three tracks, three streams, three kills
Endpoint hi-res capability
Qobuz Connect plays 24/192 direct to the same WiiM Ultra flawlessly
Endpoint asymmetry
Every RAAT dropout in the window came from the WiiM Ultra:
[Linkplay Technology Inc. WiiM Ultra @ ...] [raatclient] GOT {"status":"Dropout","samples":49152}
Zero came from the Naim Mu-so, rendering the same stream at the same moments. Per-endpoint processing speed on the same track differed sharply: WiiM 24.5x, Mu-so 89.9x. Both draw from the same Core-side buffer, so I read this as which endpoint fails first as the buffer thins, not as immunity.
What I am asking
Why does the Core’s Qobuz fetch under-deliver against its own min: requirement on a 900 Mbps connection with a 56 ms round trip to the CDN?
Is min: compared against genuinely available bandwidth, or against a rate the Core’s own fetch pacing determines? Given the table above, this now looks like the central question. If it is the latter, poor connection is largely an artifact and the kills need a cause found elsewhere. Relatedly, the min: figure is not constant for the same tier: it appears as 3462, 3472 and 3480 on one day and 3901 on another.
Given both endpoints share one Core-side buffer, is there a per-endpoint buffer or timeout that would explain the WiiM failing while the Mu-so does not?
This Core is on the early access channel, 2.71 build 1684. Is this a known regression there, and does the general release behave differently?
Happy to attach the extracted log sets: the poor-connection and dropout lines, the GC and heap stats for the kill windows, and the per-endpoint [PLAYING @ ...] trace.
We have been through the logs from that system and can now tell you where this is, with numbers. The analysis in your post is right on two points and wrong on the ones that matter, so let us go through it in order.
The endpoint asymmetry is the answer, and the report set it aside. In the most recent archive there are 132 dropout events. All 132 came from the WiiM Ultra. None came from the Naim Mu-so.
The premise that led the analysis past that is not correct. The two endpoints do not draw from one Core-side buffer. Each endpoint in a grouped zone has its own audio source, its own audio and clock ports, its own stream and its own buffer, and keeps its own dropout accounting. So the Mu-so’s zero is not one device surviving a shared buffer that thinned. Its buffer never ran dry while the WiiM’s did, on the same content at the same moments.
Both endpoints receive an identical stream. We checked what is actually sent:
Same rate, same depth, same channel count. There is no asymmetry in what leaves the Core.
The network path to each is equally good. Round trip time measured at every stream setup:
Mu-so n=194 median 781us p90 912 max 984
WiiM n=194 median 788us p90 878 max 1041
Both under a millisecond with a tight distribution. And the warnings about excessive round trip time went overwhelmingly to the Mu-so, 47 against 2, which is the device with no dropouts at all.
The poor connection table in the report cannot support its conclusion. Of 2,651 such warnings in this archive, exactly zero have a delivered rate at or above their own stated minimum. That is not a property of your network, it is the logging condition: the line is only written when the rate falls below the minimum. Any group of those warnings is therefore bounded above by its own threshold, so the best value in each group will always land just underneath it. Reading a bandwidth ceiling off that set is reading the filter, not the connection.
The data the analysis needed is in the same logs and points the other way. A separate completion line reports the achieved speed for every request, whether or not a warning fired. Across 1,288 of them:
delivered median 3,355 p75 4,430 p95 5,463 max 8,126 kbps
required min median 1,906 p75 2,858 p95 3,616 max 6,324 kbps
The fetch runs at roughly 1.8 times the requirement on median, and 28 percent of requests clear 4 Mbps. So it is not paced to the stream’s bitrate, and that part of the analysis does not hold.
On the bandwidth ceiling the report identified. Nothing in those 1,288 requests exceeds about 8 Mbps on a 900 Mbps line, and that observation is accurate. It is not evidence of a fault. Content is fetched in blocks rather than as one continuous stream, and at the round trip in play a single block request cannot show a higher figure regardless of how much bandwidth is available. The number is a property of measuring a small transfer, not of your connection, and it is why the delivered rate stays well clear of the requirement in the table above without ever looking like a gigabit link.
The second point it got right is that the Core had the CPU. We checked processing speed immediately before each of the 132 dropouts: median 44.3 times realtime, maximum 99.6, and never once below ten. The Core had a fortyfold margin at every single dropout. It was not compute.
So the position is this. Same stream, same latency, same subnet, both wired, Core with ample headroom, and one endpoint starves 132 times while the other never does once. Everything on our side and on your network is excluded by measurement rather than by argument. The WiiM Ultra is not sustaining a 32 bit 96 kHz RAAT stream on your setup, and the Naim Mu-so is.
One consequence worth knowing. When any single endpoint in a grouped zone falls far enough behind, playback stops for the whole zone, not just for that endpoint. So the WiiM was ending playback on the Mu-so as well, and the message about slow media is the text attached to that rule. It does not identify which device caused the stop, which is why this looked like a source or network problem for as long as it did.
Where that leaves us. This is not new to us. We have had reports of WiiM endpoints dropping out on higher resolution RAAT across several models going back to early last year, and we have raised it with the manufacturer through our partner. Your case is the clearest evidence we have, because the network side is so unambiguous, and we are adding it. We are not going to give you a timeline.
Two things you can do. First, in that zone’s device setup, please raise Resync Delay to between 500 and 1000 ms. In another case this bought hours of uninterrupted playback. It is a workaround, not a fix.
Second, please play the same 24/96 track to the WiiM alone, then to the Mu-so alone, then grouped again, and tell us what happens. That tells us whether the WiiM fails regardless or only when it has to stay in step with another device, and it is the one thing our data cannot answer.
While you are testing, it is worth temporarily removing the convolution filter from that zone. It is the only processing difference between your two zones, and taking it out makes the comparison clean. We do not expect it to matter, given the headroom above, but it is a free variable to eliminate.
I disabled convolution filters and ran WiiM and Mu-So separately.
I set the WiiM Resync Delay to 1000ms. That seemed to help provided that I limit Qobuz streaming settings to 96 kHz. Each device (solo or grouped) played back successfully with Qobuz limited to 96 kHz
Each device fails (played solo) if Qobuz is allowed to send 192 kHz data, although the Mu-So is somewhat more robust. Each device was originally limited to 96 kHz so downsampled. When I removed the downsampling from the Mu-So, it still failed but not as rapidly.
WiiM Resync Delay @ 1000ms + Qubuz set to max 192 kHz + WiiM set to 96 kHz - FAILS
Naim Mu-So + Qobuz set to max 192 kHz and Mu-So set to 384 kHz max. This played okay for longer, but eventually this too cut out - timer kept counting, track did not skip, but no sound.
I set the Mu-So Resync Delay to 1000ms as well, and retried the 192 kHz test. It played Kissing the Lipless until 3:04, then cut out. Next track Mine’s Not a High Horse made it only about 45 seconds.
The more detailed report from Claude is found here.
We have tried to request a new subset of the logs, but something went wrong. Probably the Roon server is offline. Would you kindly power on your Mac or start Roon?
Thanks, the logs came through on the second attempt recently. The short version is that they settle one of your questions completely; they leave the most interesting one untouched, and there is a separate finding about your extension at the end.
They do not cover your test window. The set covers 22 to 24 August and contains nothing above 24/96, so your 192 kHz runs from the 21st are not in it. That is the part we most want to look at, so we will need you to run it again. Details of what would help are at the end.
What they do settle: the fetch is not the constraint. Across 513 completed requests:
delivered median 6,208 p75 6,916 p95 7,743 max 10,316 kbps
required poor connection thresholds cluster between 2,983 and 3,540
Delivery runs at roughly twice the requirement and peaks above 10 Mbps. That is higher than the previous set, where the maximum was 8,126, and it closes the pacing question with measurement rather than argument. It also retires a caveat we raised ourselves: we had said the observed ceiling was an artefact of measuring small transfers, and this set shows the fetch going well past it when the content asks for it.
The endpoint asymmetry has not changed. All 17 dropouts in this window came from 10.10.10.188, the WiiM Ultra. None came from 10.10.10.116, the Mu-so.
One correction to the report. It states that 96 kHz was clean across the board, zero dropouts in any configuration. That held for your test session, but not since. In these three days, all at 24/96 and below, there were 17 dropouts and playback stopped twice:
08/22 12:35:10
08/24 10:12:24
So the workaround has taken this from unusable to occasional rather than to clean.
On the buffer figure near the end of a track. This underpins the blind spot claim and it also affects the earlier report, so it is worth being precise about.
The buffer percentage falls as a track approaches its end, and that is how it is meant to behave. The buffer holds the part of the track that has been fetched but not yet played. Near the end there is very little left to hold, so the figure declines toward zero no matter how fast the connection is. A reading of 2% with ten seconds of music remaining is correct and healthy. The same 2% thirty seconds into a five-minute track is starvation.
The number only carries meaning relative to how much of the track is left. Your earlier report set a track sitting at 2% against another at 100% in the same session and read that as evidence. Without the playback position for each, those two figures are not comparable.
On the kill rule and scrobbling being read together. Those are three separate mechanisms and none of them is a fault detector.
The stream kill has a stated condition, which your own logs quote: more than three seconds dropped within the last thirty. A brief dropout can be plainly audible without reaching that, and letting it pass is deliberate. If every audible glitch ended the stream, playback would stop constantly on marginal equipment, which is worse than the glitch.
Roon’s own play history counts a track once it has played for more than thirty seconds, or more than a third of its length.
Scrobbling to
or ListenBrainz uses a different rule again: four minutes played, or half the track length, whichever comes first, and tracks of thirty seconds or less never scrobble at all.
All three are about how much played, not about whether it played cleanly. So a track that suffered an audible dropout in its final fifteen seconds will normally still be recorded and still be scrobbled, because by then it has comfortably passed every one of those thresholds. That is correct behaviour rather than a blind spot, and it is not evidence about audio integrity in either direction.
On sample rate conversion as the correlating factor. This is the most useful thing in the report and we want to test it. It fits your fourth test, where native 192 passthrough to the Mu-so lasted longer than 192 downsampled to 96.
One thing it cannot be is CPU. Your own screenshots show processing at 29.5x and 33x realtime on the converting paths, so the Core has ample margin either way. If conversion is genuinely the variable, the mechanism is elsewhere.
What would help most, and it is four short runs. Please note the clock time each one fails, to the minute, and tell us your timezone:
Qobuz at 192, playing to the Mu-so alone, device set to 384 kHz maximum so Roon passes it through untouched
Qobuz at 192, Mu-so alone, device set to 96 kHz so Roon downsamples
Qobuz at 192, WiiM alone, passthrough
Qobuz at 192, WiiM alone, downsampled
That pairs each endpoint against itself with conversion as the only variable, which is what your correlation needs in order to be checked rather than inferred.
Your fourth test also produced something different from the rest: the Mu-so cut out with the timer still counting and no track skip. A stream that stops producing sound while the transport keeps running is not the dropout mechanism, so please flag that one separately if it happens again.
Separately, something in your registry worth knowing about. Your server’s RoonServerRegistry/RoonApi folder holds 21,392 files, all of this shape:
They come from your own extension, com.roon-bridge.claude. Over these three days it also made 7,304 get_zones calls and 1,855 matched pairs of queue subscribe and unsubscribe.
We create a persistent registry entry per browse session and never remove it, so anything supplying a fresh session key on each call leaves a file behind permanently. We are filing that, because an extension should not be able to grow the server’s database directory without limit.
In the meantime, if your extension reuses one stable session key for its album index checks instead of generating a new one each time, it will reuse a single entry rather than creating thousands. The existing files can be deleted with Roon Server stopped; they hold cached navigation state and nothing of yours.
We do not think this is causing the dropouts, given the compute margin at every one of them. But a folder with twenty thousand files in it is worth clearing, and it will keep growing until the session key stops changing.
Okay - completed the new set of tests tonight. Here’s the report from Maya (agent running on Claude Code/Sonnet 5).
Two things I’ll add:
I have noticed the 10:34pm banner in the Roon app about “Qobuz media loading slowly” tends to appear fairly often when Roon is attempting to stream a 192 kHz file from Qobuz.
When playback failed on the WiiM, the sound broke up and it immediately advanced to the next track.
When playback failed on the Naim, the output went silent but the time kept counting as if it was playing fine through the end of the track. Sound resumed at the start of the next track. If that track was another at 192 kHz, it too went silent (as recorded below). In one instance, when Roon Radio added a next track below 192 kHz, that track played just fine.
@vadim please let me know if you want the screenshots or any additional logs or data. Thanks for all the close attention on this!
monty
Roon dropout test session — 2026-08-27
Prepared by Maya (Monty’s music assistant) for Monty to review and forward to Roon support. Times are Central (CT), 2026-08-27, taken from the file timestamps on Monty’s own signal-path screenshots (~/Documents/Roon Debugging/), which are precise to the second — these supersede the earlier live-called-out times.
Purpose
Follow-up to Roon support’s request for 4 short listening tests (Mu-so / WiiM, signal passthrough / downsampled to 96kHz, all at Qobuz 192kHz) to help isolate whether the dropout trigger is “192kHz involvement” generally or the resampling engine specifically. Monty added a 5th condition per device on his own initiative: Qobuz account capped to 96kHz, so no 192kHz content touches the pipeline at all, as a control.
Setup for all tests
Filters/convolution and volume leveling turned off (except where noted). Track used throughout: The Shins, Chutes Too Narrow (20th Anniversary Remaster), starting from “Mine’s Not a High Horse” or “So Says I,” restarted from 0:00 for each run so results are comparable.
“Mine’s Not a High Horse” cut at 0:23 (≈10:33:33 PM) and skipped ahead; on repeat got rough at 0:17; “So Says I” cut at 0:14 on repeat
10:34:28 PM
Same run, mid-test
Same 192->96kHz conversion
A Roon banner appeared: “Qobuz media is loading slowly. This may indicate a network…” — worth flagging to Roon as a possible confound; a genuine network/buffering stall coinciding with this run means we can’t fully rule out network conditions as a contributor here, separate from the resampling itself
10:35:38 PM
Test 6 (bonus/control): Qobuz account capped to 96kHz
Qobuz FLAC 96kHz/24bit (no conversion needed) → WiiM
“Kissing the Lipless” completed clean; “Mine’s Not a High Horse” and the rest of the album played through with no dropout
Reading
Every 192kHz-involving condition failed within seconds to tens of seconds, on both devices, whether passed through or downsampled by Roon. Every condition with 192kHz removed entirely (Qobuz capped, device capped) played clean tonight, on both devices. That points at 192kHz content itself as the trigger, not specifically the resampling engine — resampling from 192kHz still failed, and a session with no 192kHz anywhere didn’t. The one wrinkle is the network-loading banner during the WiiM downsample run (10:34:28 PM) — it doesn’t overturn the pattern (the Mu-so downsample run at 10:17:44 PM failed with no such banner), but it’s honest to flag rather than omit.
Caveat, from Roon’s own prior data, not ours: your support letter noted 17 dropouts and 2 full stops over 22–24 August, a window where Qobuz was already capped to 96kHz. So “96kHz-and-below” is not itself a clean bill of health — it just held up for tonight’s short test runs. We looked for what was playing at your two reported full-stop timestamps (08/22 12:35:10 and 08/24 10:12:24) in our own local logs; the nearest matches were “Purple Yellow Red and Blue” by Portugal. The Man (~12:35:52) and “I Zimbra” by Talking Heads/Brian Eno (~10:12:37), both roughly 30–50 seconds after your reported timestamps — we can’t confirm the timezone basis of your numbers matches ours, so treat this as a lead, not a confirmed correlation.
Screenshots
All in ~/Documents/Roon Debugging/ (synced across hosts), named by capture time:
Screenshot 2026-08-27 at 10.01.35 PM.png — Mu-so baseline, filters on
Screenshot 2026-08-27 at 10.06.16 PM.png — Test 1, Mu-so 192kHz passthrough
Screenshot 2026-08-27 at 10.12.29 PM.png — anomaly, 48kHz
Screenshot 2026-08-27 at 10.14.37 PM.png — Test 1 repeat
Screenshot 2026-08-27 at 10.17.44 PM.png — Test 2, Mu-so downsample
Screenshot 2026-08-27 at 10.20.56 PM.png — Test 3, Mu-so 96kHz-capped control
Screenshot 2026-08-27 at 10.30.16 PM.png — Test 4, WiiM passthrough
Screenshot 2026-08-27 at 10.33.10 PM.png / 10.34.28 PM.png — Test 5, WiiM downsample (+ network banner)
Screenshot 2026-08-27 at 10.35.38 PM.png — Test 6, WiiM 96kHz-capped control
Four runs, ungrouped, with the other endpoint fully disabled rather than paused. Same track each time, played to the end rather than stopped at the first fault:
Mu-so, 192 passthrough
Mu-so, 192 → 96
WiiM, 192 passthrough
WiiM, 192 → 96
Note the wall-clock time of each run and pull the logs the same day. Thank you!
A remark I’ve received from WiiM support:
Upon internal verification, we have not received reports regarding this issue from Roon Labs or other users. However, we will reach out to Roon again to confirm.
Mu-So, 192kHz passthrough - 2:54a CT - cuts out at 0:20, playback clock keeps running; second track cuts out at 0:17, playback clock keeps running (I paused at 0:30)
Mu-So, 192 → 96 - 3:01a CT - cuts out at 0:26, playback clock keeps running; second track cuts out at 0:15; playback clock keeps running (I paused at 0.30)
WiiM, 192kHz passthrough - 3:15a CT - played to 0:xx (didn’t get it) then cuts and immediately skips ahead; second track plays to 0:28 then cuts and immediately skips ahead
WiiM, 192 → 96 - 3:19a CT - played to 0:32 then silence, runs 2 sec more, then skips ahead to next track; second track plays to 0:26 then silence, runs 2 sec more, then skips ahead
I noticed running test 4 a couple more times that the timecode where it cut out would range over a few seconds - it wasn’t repeatably the same.
Roon showed a “Qobuz media is loading slowly” toast in the WiiM tests.
Claude report below.
monty
Chutes Too Narrow (The Shins) - four-run diagnostic, 2026-09-04
Four full-album runs, ungrouped, other endpoint fully disabled, requested by Roon support (benjamin) to isolate a mid-track dropout on hi-res Qobuz playback. RoonServer log evidence below is from RoonServer_log.txt, all times US Central (CT).
Summary
Every run shows the same root-cause signature in the RoonServer log: Qobuz fetch bandwidth running well below the stream’s required minimum, followed by RAAT reporting sustained dropouts and killing the stream. This happened on both endpoints (Mu-So and WiiM) and both sample rates (192 passthrough and 192->96), so it is not specific to one device or one resample setting - it tracks Qobuz fetch throughput.
where X is consistently ~3400-4700 kbps against a required minimum Y of ~6050-6750 kbps for this 24/192 stream - i.e. Qobuz is delivering roughly half to three-quarters of the bitrate the stream needs, sustained over 10-20+ seconds before each failure.
The two endpoints fail differently, and this is worth noting on its own: on the Mu-So (Naim), the fetch starvation causes the audio to drop out silently while the displayed playback position counter keeps advancing normally - it does not skip or advance to the next track, it just goes quiet mid-track. On the WiiM, the same starvation trips Roon’s dropout counter hard enough that it kills the stream outright and skips ahead to the next track (StoppedEndOfMediaUnnatural, confirmed in the log every time). Same root cause, different failure mode per output driver.
That starvation is followed directly by:
[raatclient] GOT {"status":"Dropout","samples":N} (repeated, N growing toward buffer size)
Warn: [WiiM] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
Warn: [WiiM] [zoneplayer/raat] too many dropouts (Linkplay Technology Inc. WiiM Ultra). stopping stream
Info: [zone WiiM] OnPlayFeedback StoppedEndOfMediaUnnatural
(Mu-So shows the equivalent starvation via repeated [prebuffer] sleeping in read -- this isn't good rather than the RAAT dropout counter, since it’s a different output driver, but the same underlying “poor connection kbps” fetch shortfall precedes it.)
Note on timing precision: the log’s own track-transition timestamps (“loading”/“playing” events) lag the actual audible dropout by several seconds - confirmed by direct comparison against Monty’s own listening. Use the “poor connection” and “Dropout”/“Killing stream” timestamps below as the reliable record of when the fault occurred; do not rely on inter-track duration deltas for precise timing.
Run 1 - Mu-So, 192kHz passthrough
Started ~2:54am CT.
Direct listening (Monty): track 1 dropout at 0:20, track 2 dropout at 0:17. Playback position counter kept advancing through both dropouts - audio stopped, displayed clock did not. Stopped manually at 0:30 into track 2 after the pattern repeated.
Log: sustained poor connection kbps warnings from 2:54:35 onward (4452 → as low as 3385 kbps against a 6268 kbps minimum), with [prebuffer] sleeping in read -- this isn't good repeating continuously through the starvation window.
Run 2 - Mu-So, 192 → 96kHz
Started ~3:01am CT.
Direct listening (Monty): track 1 dropout at 0:26, track 2 dropout at 0:15. Same clock-keeps-running symptom. Stopped manually at 0:30 into track 2.
Log: same poor connection kbps pattern from 3:01:26 onward (5069 → as low as 3515 kbps against 6268 kbps minimum).
Run 3 - WiiM, 192kHz passthrough
Started 3:14:00am CT.
Log-confirmed dropout/kill-stream events:
3:14:42-45am - poor connection (4177-4333 kbps vs 6268 min), RAAT dropout samples climbing to 98304, stream killed 3:14:45am
3:15:09-13am - same pattern, stream killed 3:15:13am
3:15:36-40am - same pattern, stream killed 3:15:40am
3:16:05-09am - same pattern, stream killed 3:16:09am
A fifth confirmation run (WiiM, 192->96, restarted clean from track 1 at 3:23:58am CT) showed the identical pattern again:
3:24:37-41am - stream killed 3:24:41am
3:25:15-18am - stream killed 3:25:18am
3:25:39-42am - stream killed 3:25:42am
Conclusion
The fault is not endpoint-specific and not resample-specific - it reproduces on Mu-So and WiiM, at both native 192kHz and downsampled 96kHz. Every failure is preceded by a sustained Qobuz fetch-throughput shortfall (poor connection kbps well under the stream’s required minimum) lasting roughly 10-30 seconds before Roon’s dropout/kill-stream logic fires. This points at the Qobuz fetch path / network throughput to the Roon Core as the root cause rather than either playback endpoint or the resampling engine.
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.
