Roon Instability and Connectivity Issues with SOtM sMS-200 Neo During Peak Hours (ref#RQ8VYA)

technetpartner · June 29, 2026, 8:33pm

What app are you having the slowness issue with?

· Roon

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?

· I only have one Roon remote to test with

Please try to restart your Roon Remote (controller) app

· No, the issue is still the same even after a restart

What is the operating system of your Roon Remote (controller)?

· iOS

Reinstall Mobile Roon Remote App

· No, I am still having the issue even after reinstalling

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?

· Windows

Timestamp of issue occurrences

· I noticed the slowness occur the rush hour, in midle of the night or midle of the day works normal, every evenig from 4pm to 10pm is nightmere with this app

Describe the issue

Roon instability and connectivity issues with SOtM sMS-200 Neo during peak hours. Dear Roon Support Team,

I am writing to seek assistance with persistent stability issues in my Roon setup. While my system works fine during off-peak hours (night/working hours), it becomes virtually unusable during the evenings when I experience frequent disconnects and playback failures.

The Problem:
During peak hours, Roon frequently fails to maintain a connection. When it does manage to detect my endpoint (SOtM sMS-200 Neo), playback often stops after only 3 seconds, followed by error messages such as "device not found" or "server not found," or the application simply hangs. Interestingly, when using the same hardware with the mconnect app, everything works perfectly, which suggests the issue lies within the Roon software/server communication rather than my local network or hardware.

My Setup:

Roon Core: Intel NUC Mini PC.

Network: Wired Ethernet (stable connection, all relevant hardware has been checked and power-cycled/reset).

Endpoint: SOtM sMS-200 Neo.

Service: Tidal integration.

Troubleshooting performed:
I have already performed extensive troubleshooting, including full network resets and restarts of both the Core and the endpoint. Given that these issues exclusively occur during peak usage hours, I suspect that the Roon backend may be struggling with high traffic, rendering the service unreliable for me at the times I most want to use it.

Could you please investigate why my Roon Core is losing connection with the SOtM endpoint specifically during high-traffic periods? Any guidance or diagnostic steps would be greatly appreciated.

Best regards,

Describe your network setup

archer c6 tp-link via lan cable

connor · June 29, 2026, 11:52pm

Hi @technetpartner,

Thank you for your post.

Roon relies on sustained TCP connections between your server and your networked Zones, and these tend to expose any latent packet loss or multicast handling issues more immediately than other music apps.

The NUC hosting the SoTM Zone shows severe packet loss in logs:

06/27 09:26:54 Trace: [SOtM sMS-200 () @ 192.168.1.182:39303] [raatclient] GOT [91] {"status":"Dropout","samples":7144}
06/27 09:26:55 Trace: [SOtM sMS-200 () @ 192.168.1.182:39303] [raatclient] GOT [91] {"status":"Dropout","samples":17363}
06/27 09:26:55 Trace: [SOtM sMS-200 () @ 192.168.1.182:39303] [raatclient] GOT [91] {"status":"Dropout","samples":22050}
06/27 09:26:56 Trace: [library] endmutation in 266ms
06/27 09:26:56 Trace: [SOtM sMS-200 () @ 192.168.1.182:39303] [raatclient] GOT [91] {"status":"Dropout","samples":22050}
06/27 09:26:57 Trace: [SOtM sMS-200 () @ 192.168.1.182:39303] [raatclient] GOT [91] {"status":"Dropout","samples":22050}
06/27 09:26:57 Trace: [SOtM sMS-200 () @ 192.168.1.182:39303] [raatclient] GOT [91] {"status":"Dropout","samples":22050}
06/27 09:26:57 Trace: [sotm] [Lossless 5,1x, 24/44 TIDAL FLAC => 24/44] [4% buf] [PLAYING @ 0:18/3:45] In Fact (feat. Gabzy) - melvitto
06/27 09:26:57 Debug: [prebuffer] sleeping in read -- this isn't good
06/27 09:26:57 Warn: FTMSI-B-OE ti/C57A06DA: poor connection kbps:864,0 (min:1667,0)
06/27 09:26:57 Trace: [SOtM sMS-200 () @ 192.168.1.182:39303] [raatclient] GOT [91] {"status":"Dropout","samples":22050}
06/27 09:26:57 Debug: [prebuffer] sleeping in read -- this isn't good
06/27 09:26:57 Warn: [sotm] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
06/27 09:26:57 Trace: [sotm] [zoneplayer/raat] too many dropouts. stopping stream
06/27 09:26:57 Debug: FTMSI-B closed file for ti/ADE44CCE; open files:0
06/27 09:26:57 Warn: [zone sotm] Track Stopped Due to Slow Media
06/27 09:26:58 Info: [zone sotm] OnPlayFeedback StoppedEndOfMediaUnnatural

Consistent dropouts of 2050 samples at this sample rate means a considerable volume of data is failing to reach the SoTM over the network.

Roon Ready is an uncompressed protocol; if you’re relying on WiFi, then the audio stream will be vulnerable to interference. Is the SoTM itself hardwired in addition to the server?

If so, then overzealous network management software can sometimes route packets in a manner Roon doesn’t expect, or otherwise interfere with Roon Ready. What is the actual network topology between Roon Server (the NUC) and the SoTM Zone?

Here are our network best practices, for reference:

We’re happy to provide more granular assistance to ensure this endpoint works reliably in this space. The more detail you can provide about your setup and the network equipment involved, the faster we can likely resolve or relieve this symptom. Thank you!

technetpartner · June 30, 2026, 8:21am

"To confirm: the topology is fully wired (Ethernet). The SOtM is connected directly to the router with no switches in between. I have tested it extensively with mConnect, and it works perfectly without any issues, even during peak hours.

The problem is strictly Roon-related and correlates with network/server load during peak hours. The behavior is unstable:

Sometimes the Roon Server is unreachable.
Sometimes the server is visible, but the SOtM zone is missing.
Sometimes everything is visible, but playback won’t start or drops out immediately.
Everything works flawlessly late at night when the network traffic is low.

Since mConnect works flawlessly on the same hardware/cabling, it proves there is no physical layer fault. The Roon RAAT protocol seems to be extremely sensitive to even minor broadcast/multicast latency or temporary spikes in CPU load on the NUC caused by Roon’s background processes (like library analysis) coinciding with peak network traffic. What specific logs or diagnostic tools can I use to determine why Roon specifically is failing to maintain the handshake, while other protocols remain stable?"

vadim · June 30, 2026, 11:17am

Hello @technetpartner,

Thank you for confirming the topology and for the patience while we dug through the diagnostic logs from your Roon Server.

First, to address your theory about Roon’s backend being overloaded during peak hours: that is not what is happening here. Roon’s servers handle requests from users across every time zone globally, so an evening slowdown specific to your location would not be explained by our infrastructure being “busy” at that time. What we found in your logs points somewhere much more specific - and it actually explains exactly why mConnect keeps working while Roon does not.

Why mConnect works and Roon doesn’t

These two apps talk to your Tidal account in fundamentally different ways:

mConnect tells the SOtM device “here is the Tidal track, go fetch it yourself.” The SOtM then pulls the audio directly from Tidal’s servers and can buffer ahead generously, since it only ever needs to feed that one device.
Roon (via RAAT) has to work differently: your Core needs to be able to play to multiple endpoints simultaneously and switch between them instantly, with tight synchronization across zones. Because of this, Roon does not pre-buffer large amounts of audio per device the way a single-purpose app like mConnect can. Instead, your NUC pulls the stream from Tidal and relays it to the SOtM in something much closer to real time.

This means if anything slows down the connection between your NUC and Tidal specifically, Roon has very little buffer to absorb that slowdown before it causes a dropout - while mConnect, with its much deeper per-device buffer and no relay step, can ride through the same dip without issue.

What the logs show

During the evening hours you described, we found repeated entries where the data arriving from Tidal’s servers was well below what the stream needed to play smoothly, for example:

poor connection kbps:753 (min required:1803) — only 42% of what was needed
Too many dropouts. Killing stream

This pattern repeats multiple times in the evening window and is consistent with congestion between your ISP and Tidal’s servers at that time of day - not a problem with your Roon setup, router, or the SOtM device itself.

What you can try

Lower your Tidal streaming quality to High (Settings → Services → Tidal) during evening hours. This roughly cuts the required bandwidth by more than half, which should make playback far more resilient to that evening congestion.
As a way to test the ISP congestion theory directly: since you’re on Windows, you could try connecting through a VPN routed through a different region during the evening hours and see if the dropouts disappear. If they do, that confirms the bottleneck is specifically on the route between your ISP and Tidal, not your local network.

Let us know if lowering the quality helps - that would confirm the bandwidth theory directly.

technetpartner · June 30, 2026, 1:07pm

Thank you for the explanation. However, I find it difficult to accept that ‘ISP congestion’ is the root cause here. I have a 300 Mbps fiber connection, and at the exact times when Roon fails to play music, I am able to stream 4K video content on my TV through the same router without any buffering or stuttering.

If my ISP were congested, 4K video streaming—which requires significantly higher bandwidth—would also suffer. The fact that high-bitrate video works perfectly while Roon fails suggests that the issue is not with the available bandwidth, but rather with how Roon handles the specific network path to Tidal compared to how other services handle their data.

Video streaming services utilize massive, localized CDNs and aggressive buffering, which makes them resilient to minor routing variations. If Roon’s architecture relies on a relay model that is so sensitive to minor latency or routing fluctuations that it cannot compete with the stability of a standard 4K video stream, then it appears Roon is simply not compatible with my network environment.

At this point, I have invested time and money into this setup, and it is not providing the service it was intended to. If this fundamental architectural limitation cannot be overcome, I would like to discuss a refund for my Roon subscription.

benjamin · June 30, 2026, 5:03pm

Hey @technetpartner,

Thank you for the detailed follow-up, and I completely understand the frustration here, you’ve invested in a good setup, you’ve done genuine troubleshooting, and the evening failures are real and repeatable. I want to be clear that we’re not dismissing what you’re experiencing; the logs back it up. Where we differ is on the cause, and I’d like to walk through exactly what the diagnostics show so you can see how we reached our conclusion.

First, the part you’re right about: the timing is not in your head. The diagnostic warnings cluster heavily in the 5pm–10pm window and are nearly absent in the late-night and midday periods you say work fine. So the evening correlation is solid.

Where the logs point somewhere different from your theory is the location of the bottleneck. Every dropout in your logs is immediately preceded by two entries: a “poor connection” warning from our Tidal download layer, and a “prebuffer sleeping in read” message. In plain terms, the playback buffer is emptying because audio isn’t arriving from Tidal fast enough, and only then does the SOtM report a dropout. The SOtM is the symptom, not the source. The “poor connection” lines even quote the numbers: repeatedly the measured download rate from Tidal falls far below what the track needs (for example 753 kbps arriving against 1803 required, and several worse). When that happens, the stream gets starved and killed.

I also want to directly rule out the two mechanisms you proposed, because we checked both:

It is not your Server’s CPU or background library analysis. The performance stats are essentially flat across the evening hours, no load spike at peak, and your audio analysis runs overnight (around 5am), not in the evening window.
It is not our backend being busy. Our servers field requests from every time zone simultaneously, so they have no notion of “your evening.” And critically, the failing measurements are all on the path between your Server and Tidal specifically, not anything on our side.

On the mConnect comparison, this is actually the most useful clue, and it’s consistent with everything above rather than contradicting it. mConnect hands the track URL straight to the SOtM, which then pulls from Tidal on its own and buffers deeply, because it only ever feeds that one device. Roon works differently by design: your Server pulls the stream and relays it to the endpoint in close to real time, with a shallow buffer, so that it can stay synchronized across multiple zones. That shallow buffer is exactly what makes Roon expose a source-side slowdown that mConnect’s deep buffer quietly rides over. So mConnect succeeding doesn’t prove the path is clean, it proves mConnect is better at hiding the same dip.

Your 4K-video point is a fair one to raise, so let me address it head-on rather than wave it away. 4K streaming and Roon-via-Tidal aren’t a like-for-like test. Video services are delivered from CDN nodes typically inside your ISP or very close to it, with several seconds of adaptive buffer and a bitrate that silently steps down the instant the connection tightens, you’d never see it stutter. The Tidal stream Roon relays comes from a different origin over a longer, more contended route, at a fixed lossless bitrate that cannot adapt down, with very little buffer to fall back on. So a flawless 4K stream and a failing Roon stream at the same moment are fully consistent with a route-specific bottleneck to Tidal. “300 Mbps fiber” is your total capacity; it doesn’t tell us the throughput to one particular distant server at 8pm, which is the number that actually matters here.

Two things will let us confirm this conclusively and, hopefully, fix it:

Lower your Tidal streaming quality to High (Settings → Services → Tidal) during the evening. This cuts the required bandwidth by more than half, which should let playback ride through the evening congestion. If the dropouts ease, that confirms the bandwidth diagnosis directly.
Run the VPN test. Since you’re on Windows, connect through a VPN routed via a different region during a bad evening window and try playback. If the dropouts disappear over the VPN, that pinpoints the bottleneck to the route between your ISP and Tidal, because the only thing that changed was the path, not your hardware, your Server, or the SOtM.

This isn’t a fundamental architectural limitation that can’t be overcome, it’s a throughput/routing issue on one specific path, and the two steps above either resolve it or tell us precisely where to point your ISP. If you can run even just the VPN test and report back what happens, we’ll know exactly what we’re dealing with.

Thank you for sticking with this

technetpartner · July 1, 2026, 7:55am

"Thank you for your detailed response, but I believe the “bandwidth bottleneck” diagnosis does not explain the full picture.

My main point is that Tidal performs flawlessly on multiple other devices simultaneously at all times; the issue only occurs when combining Tidal and Roon. If this were strictly a bandwidth issue on my ISP’s end, other devices would be experiencing the same drops, which they are not.

More importantly, the streaming issues are only half of the problem. The entire communication process between the Roon App, the Server, and the endpoint (SOtM) is highly unstable:

Server Connectivity Issues: The App struggles to maintain a stable connection to the Roon Server itself. The account/login window appears and disappears intermittently, forcing me to fight to establish a stable connection.
Endpoint Discovery: The SOtM device frequently disappears and reappears in the App, even though it remains fully accessible and stable on my local network.
Critical Failures vs. Buffering: Even when a connection is established, once playback begins (at the moment Roon initiates the handshake with Tidal), the music either doesn’t play at all, or it starts and immediately cuts off. Crucially, the system doesn’t just pause or buffer; it disconnects the SOtM or triggers a “Roon Server not found” error. This indicates a complete breakdown of the communication protocol rather than a simple streaming slowdown.

I will perform the quality reduction and the VPN test again as requested, just for the sake of completeness—though I recall from my previous attempts (including using a work laptop) that these did not resolve the issue.

Please investigate the logs further, focusing on the stability of the “handshake” and keep-alive signals between the Roon Server and the SOtM. The problem is clearly in the communication between the App, the Core, and the endpoint, not just the Tidal bitrate. I look forward to a more in-depth analysis of these connection drops."

vadim · July 1, 2026, 12:39pm

Hi @technetpartner,

Thanks for pushing us to dig deeper into the handshake/keep-alive side of this instead of stopping at Tidal bitrate. We went back through the full log set (RoonServer, RAATServer, and Roon remote logs) and found two genuinely distinct problems, plus a network-topology issue that’s a strong candidate for the root cause.

1. Tidal bandwidth shortfalls that killed the stream

Date	Time	Kill events	Bandwidth (actual vs required, kbps)
06/07	17:55:44-17:56:12	2	813 → 777 (needed ~1154); then 1832 → 688 (needed ~2070)
06/22	21:08:18-21:08:40	2	-
06/26	08:20:02	1	nearby tracks 700-1150 vs 1250-1950 (morning, not evening)
06/27	09:24:39-09:27:03	13 (worst burst in the whole log set)	507-1238 vs 1667-1803 (as low as <50% of required)
06/29	17:35:20-17:35:36	2	1697 → 1433 (needed 3264)

20 confirmed kill events total, plus 386 “poor connection” warnings that didn’t quite cross the kill threshold. Worth noting: the single worst burst happened at 9:24 AM on 06/27, not in the evening - so this isn’t purely an evening-only pattern.

2. SOtM connection problems independent of Tidal bitrate

Issue	Count	Cluster	Example
TCP disconnect (`OnDisconnected`)	206	spread across the whole period, ~4-6/day	`[SOtM...@192.168.1.182:45897] OnDisconnected: BeginRead ead count is 0`
Zone state → Disconnected	166	same	`[raat]... => Disconnected`
Audio format negotiation failure	80	concentrated 05/30, 16:35-22:23	`GOT... {"message":"RAAT__OUTPUT_PLUGIN_STATUS_FORMAT_NOT_SUPPORTED"}`
Device open failed	4	05/30, 18:52-18:53	`Track Stopped Due to DeviceOpenFailed`
Endpoint lost	26	05/30-05/31	`Track Stopped Due to LostEndpoint`

These are handshake and connection-level failures, separate from the bandwidth issue above. Notably, at 09:27:19-09:27:41 on 06/27 - right after the 13-event Tidal burst - the SOtM also dropped its TCP connection outright, so on that morning both problems stacked on top of each other.

3. Network topology - the part we think matters most

This is the piece that best explains why the issue is inconsistent and endpoint-specific rather than a clean bandwidth story:

Your SOtM (192.168.1.182) and the NUC (192.168.1.120) are on 192.168.1.0/24.
Your WiiM Amp, which shows the same kind of disconnect pattern in these logs, sits on 192.168.0.239 - a different subnet (192.168.0.0/24).

That split strongly suggests two routers/double NAT on your network (for example, your ISP router handing out 192.168.0.x, with the TP-Link Archer C6 behind it handing out its own 192.168.1.x). Roon’s device discovery relies on multicast traffic, which by default does not cross subnet boundaries - that alone can cause endpoints to intermittently vanish and reappear in the app even while they’re reachable.

On top of that, your Roon remote logs are picking up multicast discovery traffic from at least four subnets that don’t match any of your own equipment:

[SOOD] Adding User IP 192.168.88.13   -> FOUND BROKER OPCX3040
[SOOD] Adding User IP 10.0.0.53       -> FOUND BROKER Mac-mini-Roon
[SOOD] Adding User IP 10.0.0.51       -> FOUND BROKER "roonserver"
[SOOD] Adding User IP 192.168.188.152 (no broker name)

These brokers appear and disappear every 30-35 seconds (FOUND BROKER / LOST BROKER ... not seen in ~32-34s), adding constant background churn to Roon’s discovery process. None of this corresponds to your own hardware, which points to broadcast-domain leakage from neighboring networks sharing your ISP’s infrastructure (common on GPON/MDU setups without proper client isolation), or possibly a VPN/virtual network adapter active somewhere on your own network.

What we’d like you to check:

Can you confirm whether you have two routers/a double-NAT setup at home, and whether the WiiM Amp is connected to a different one than the SOtM and NUC?
Do you live in a multi-unit building where the internet connection is shared infrastructure (fiber/GPON) rather than a dedicated line?
If you have any VPN client or virtual network software running on any device on this network (including the “work laptop” you mentioned testing with), please disable it during a test session and see if the SOtM stays connected.

This is a more specific and testable lead than the bandwidth theory alone, and it fits the intermittent, cross-device nature of what you’re describing far better.

technetpartner · July 3, 2026, 12:59pm

Hello,

I live in a detached house and indeed, I have two routers—one upstairs and the other downstairs in the living room. The WiiM is running in the upstairs office on a different router than the sMS-200 (sotm) and the NUC. I have a separate fiber optic connection from my provider. Both the NUC (running the Roon server) and the SOtM are connected via cable to the downstairs router. The same issue occurs even without the work laptop with the VPN (which usually stays in the office).

vadim · July 3, 2026, 1:22pm

Hello @technetpartner,

Thank you - this confirms the root cause. You have two separate routers creating two separate subnets (192.168.0.x upstairs and 192.168.1.x downstairs), and multicast traffic that Roon relies on for device discovery and keep-alive does not cross subnet boundaries by default.

This explains everything: the SOtM and NUC are on the same subnet so playback can work, but any multicast disruption between the two routers causes the intermittent “Roon Server not found” errors and endpoint disappearing. The foreign brokers we saw in your logs (192.168.88.x, 10.0.0.x) are also consistent with broadcast domain leakage through your ISP’s infrastructure when two routers share the same fiber connection.

To fix this you have two options:

Option 1 - Bridge mode (recommended): Configure one of the two routers in bridge/access point mode so both serve the same subnet. Typically you would put the upstairs router in bridge mode and let the downstairs router handle all DHCP and routing. This eliminates the double-NAT and puts all devices on a single flat network.

Option 2 - IGMP proxy(not supported): If you need both routers to remain in router mode, enable IGMP proxy/forwarding on the router that connects the two - this allows multicast traffic to cross subnet boundaries. The exact setting depends on your router models.

noris · July 8, 2026, 9:43pm

Hello @technetpartner,

Wanted to follow up on this. Were you able to try putting one of the routers into bridge or access point mode so everything sits on a single subnet, or, if you need both routers to stay active, enabling IGMP proxy or forwarding on the router that links the two networks? If you have had a chance to check those network settings, let us know what you found and we can take it from there.

Please note, if we don’t hear back from you this thread may close automatically soon. If the thread auto-closes and you need further assistance, please submit a reopen support request via the technical support help form below and specify that the issue should be reopened. Thank you.