Roon client on Windows 10 doesn't see connected audio devices intermittently (ref#TVLJUH)

ISkIN · May 13, 2026, 1:11pm

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

· There is a Roon Server installed on a PC with Windows 10 and a Roon client installed on another PC with Windows 10 (connected via Ethernet through a router).
The client does not see any connected audio devices/zones.
Only one audio output is available directly on the Roon Server, and all the others connected to the current computer are not (the PC with the Roon client has a standard system audio output and a USB DAC).
After rebooting the PC, this is most often fixed, but then it occurs again. Perhaps this is a problem with the RAATServer.

Tell us about your home network

· Roon Server -> Ethernet -> router Tplink Archer C6 -> Ethernet -> Roon client PC

benjamin · May 14, 2026, 11:19pm

Hi @ISkIN,

This looks like Roon Remote on the Windows 10 client is intermittently losing sight of the local audio endpoints on that machine, rather than a problem with the audio devices themselves.

To narrow it down, there are two things I’d like to check first:

Does the Windows client still show the same audio devices in Device Manager and in Windows sound settings when Roon stops seeing them?
Are the client PC and the Roon Server both connected by Ethernet only, or is either machine also using WiFi, powerline, or a switch in between?

In the meantime, please try this on the client PC when the zones disappear: open Roon Settings > Audio, leave it open for a moment, and then restart the Roon Server service on the server machine. If the devices come back after that, it points us toward a discovery or RAAT service issue rather than a hardware fault.

If you can, also let us know whether the USB DAC is powered on and connected before Roon starts, or if it is being plugged in after the fact. That detail matters here.

Send back what you find, and we’ll take the next step from there.

ISkIN · May 17, 2026, 6:38pm

Yes, the same audio devices are always available in the device manager and play audio through other programs
Ethernet only via router

It doesn’t matter when the USB DAC was connected - in both cases, if a problem occurs, it is not displayed.
There are only two options: either there is a problem and all local audio devices (including Windows default system output, DAC, etc) are not displayed on the client Roon Remote from the very start, or there is no problem and all are displayed. The problem can also occur without a DAC connection.

At the moment, I have not been able to reproduce the problem again to check the case with the Roon Server restart, but as soon as it occurs again, I will provide the missing information. But, if I remember correctly, the problem persisted when Roon Server was restarted.

Also, if you need the logs, I can send them as soon as the problem occurs again.

noris · May 20, 2026, 11:21pm

Hello @ISkIN ,

Yes, please let us know the exact local time + date when the problem reoccurs, and we’ll enable diagnostics for your account. Did you by any chance clone one of the Windows PCs into the other one or were they set up as fresh installs? I have sometimes seen VPNs and firewalls also cause this behavior.

ISkIN · May 27, 2026, 8:27am

The problem has occurred again, so I can now provide the necessary information. Today, at about 10:00 AM, I woke the computer up from sleep mode and launched Roon Remote. The problem with the missing audio devices occurred again.

Roon suggested updating the client and the server, and after restarting both, the problem persisted. As for the installation, the latest versions of Windows were installed on the server and the client; there was no cloning. Although initially Roon Server was installed on the client computer, and then I moved it to another one (I don’t remember if I moved the database at that time).

As for firewalls/VPN, the firewall is disabled, and exceptions are specified in the VPN, so it is unlikely to cause problems. I also tried turning off all VPNs and network filtering applications, but that didn’t help, so I don’t think that’s the problem (especially since, in most cases, everything works well).

Screenshot Roon Remote

Below, I have attached a section of the Roon and RAATServer log from the moment I click “Refresh” in the list of audio devices in Roon.

Roon log

05/27 10:39:33 Info: [raatserver] [runner] Start or Connect...
05/27 10:39:33 Info: [raatserver] [runner] Start or Connect... C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe
05/27 10:39:33 Info: ConnectOrStartAndWaitForExit RAATServer, path: C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe
05/27 10:39:33 Info: ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver
05/27 10:39:34 Warn: AddTopLevel: dimlayer(314)
05/27 10:39:34 Warn: AddTopLevel: dimlayer(314)
05/27 10:39:34 Warn: AddTopLevel: capturelayer(324)
05/27 10:39:34 Warn: AddTopLevel: capturelayer(324)
05/27 10:39:34 Warn: AddTopLevel: win_spinner(4132)
05/27 10:39:34 Warn: AddTopLevel: win_spinner(4132)
05/27 10:39:35 Info: ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let's start one
05/27 10:39:35 Info: [raatserver] [runner] Status: Started
05/27 10:39:43 Info: [stats] 2234490mb Virtual, 380mb Physical, 56mb Managed, 324mb estimated Unmanaged, 1127 Handles, 36 Threads, 0.09% of runtime in GC pauses, 1ms last GC pause duration
05/27 10:39:43 Debug: threshold_minutes: 10080
05/27 10:39:44 Warn: exception starting raatserver: System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it. [::ffff:127.0.0.1]:9004
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.Net.Sockets.TcpClient..ctor(String hostname, Int32 port)
at Sooloos.RAATServer.ConnectOrStartAndWaitForExit(String path, String args, Action`1 status, ChildProcess& p)
05/27 10:39:45 Info: [raatserver] [runner] Start or Connect...
05/27 10:39:45 Info: [raatserver] [runner] Start or Connect... C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe
05/27 10:39:45 Info: ConnectOrStartAndWaitForExit RAATServer, path: C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe
05/27 10:39:45 Info: ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver
05/27 10:39:47 Info: ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let's start one
05/27 10:39:47 Info: [raatserver] [runner] Status: Started
05/27 10:39:55 Warn: exception starting raatserver: System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it. [::ffff:127.0.0.1]:9004
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.Net.Sockets.TcpClient..ctor(String hostname, Int32 port)
at Sooloos.RAATServer.ConnectOrStartAndWaitForExit(String path, String args, Action`1 status, ChildProcess& p)

RAATServer log

05/27 10:39:36 Info: Starting RAATServer v2.67 (build 1662) earlyaccess on windows
05/27 10:39:36 Info: Local time is 27-May-26 10:39:36 AM, UTC time is 27-May-26 7:39:36 AM
05/27 10:39:36 Trace: [bits] myinfo: {“os”:“Windows 10”,“platform”:“windows”,“machineversion”:206701662,“branch”:“earlyaccess”,“appmodifier”:“”,“appname”:“RAATServer”}
05/27 10:39:36 Debug: [easyhttp] [1] POST to ``https://bits.roonlabs.net/1/q/roon.base.,roon.internet_discovery.,roon.raatserver``. returned after 655 ms, status code: 200, request body size: 130 B
05/27 10:39:36 Trace: [bits] updated bits, in 677ms
05/27 10:39:36 Info: [RAATServer] creating RAAT__manager
05/27 10:39:36 Info: [RAATServer] appdata_dir = C:\Users\ISkIN\AppData\Local\RAATServer
05/27 10:39:36 Info: [RAATServer] unique_id = 35b05d98-aa4f-48ae-a3d1-e5bd7cad005a
05/27 10:39:36 Info: [RAATServer] machine_id = 07488255-4586-e728-9d3e-29b7b697ae61
05/27 10:39:36 Info: [RAATServer] machine_name = SUPERCOMPLUKTER
05/27 10:39:36 Info: [RAATServer] os_version = Windows 10
05/27 10:39:36 Info: [RAATServer] vendor =
05/27 10:39:36 Info: [RAATServer] model =
05/27 10:39:36 Info: [RAATServer] service_id = d7634b85-8190-470f-aa51-6cb5538dc1b9
05/27 10:39:36 Info: [RAATServer] is_dev = False
05/27 10:39:36 Trace: [raatmanager] starting
05/27 10:39:36 Info: [raatmanager] added codesigning key keypair_name=Roon public_key=9bb28e4e9e34ed4ff75c6a35339497cbdd3420713c941f5468571afc03555bf7
05/27 10:39:36 Trace: [raatmanager] [System Output] loaded config from C:\Users\ISkIN\AppData\Local\RAATServer\Settings\device_9b961fc2035f3dd343e04f8f136e7682.json
05/27 10:39:36 Trace: [raatmanager/windows] FOUND type=wasapi id={0.0.0.00000000}.{b70b23a7-c33d-4b81-b68e-a69458f14434} usb_id=
05/27 10:39:36 Trace: [raatmanager/windows] name=High Definition Audio Device output_name=Наушники
05/27 10:39:36 Trace: [raatmanager/windows] FOUND type=asio id={40F4F7C8-786F-49EB-8521-23CC5358D70E} usb_id=
05/27 10:39:36 Trace: [raatmanager/windows] name=TUSBAudio ASIO Driver output_name=
05/27 10:39:36 Trace: [raatmanager/windows] FOUND type=asio id={64083085-BD64-42AA-ADA3-73F51E17CAD7} usb_id=
05/27 10:39:36 Trace: [raatmanager/windows] name=XMOS USB Audio 2.0 ST 3085 output_name=
05/27 10:39:36 Trace: [raatmanager] [TUSBAudio ASIO Driver] loaded config from C:\Users\ISkIN\AppData\Local\RAATServer\Settings\device_c970e1eea47893c3cf8c1e31c8a5f514.json
05/27 10:39:36 Trace: [raatmanager] [XMOS USB Audio 2.0 ST 3085] loaded config from C:\Users\ISkIN\AppData\Local\RAATServer\Settings\device_5e315854e47d084264cd8195f66e7223.json
05/27 10:39:36 Trace: [raatmanager] initialized
05/27 10:39:37 Info: [RAATServer] running RAAT__manager
05/27 10:39:37 Warn: [raatmanager] update_bits, json string: {}
05/27 10:39:37 Trace: [raatmanager] starting discovery
05/27 10:39:37 Trace: [discovery] starting
05/27 10:39:37 Info: [discovery] [iface:VPN Work 2FA:172.30.254.43] multicast recv socket is bound to 0.0.0.0:9003
05/27 10:39:37 Info: [discovery] [iface:VPN Work 2FA:172.30.254.43] multicast send socket is bound to 0.0.0.0:61624
05/27 10:39:37 Info: [discovery] [iface:vEthernet (Ethernet):172.26.64.1] multicast recv socket is bound to 0.0.0.0:9003
05/27 10:39:37 Info: [discovery] [iface:vEthernet (Ethernet):172.26.64.1] multicast send socket is bound to 0.0.0.0:61625
05/27 10:39:37 Info: [discovery] [iface:vEthernet (Default Switch):172.27.224.1] multicast recv socket is bound to 0.0.0.0:9003
05/27 10:39:37 Info: [discovery] [iface:vEthernet (Default Switch):172.27.224.1] multicast send socket is bound to 0.0.0.0:61626
05/27 10:39:37 Info: [discovery] [iface:Ethernet:192.168.1.100] multicast recv socket is bound to 0.0.0.0:9003
05/27 10:39:37 Info: [discovery] [iface:Ethernet:192.168.1.100] multicast send socket is bound to 0.0.0.0:61627
05/27 10:39:37 Info: [discovery] [iface:Loopback Pseudo-Interface 1:127.0.0.1] multicast recv socket is bound to 0.0.0.0:9003
05/27 10:39:37 Info: [discovery] [iface:Loopback Pseudo-Interface 1:127.0.0.1] multicast send socket is bound to 0.0.0.0:61628
05/27 10:39:37 Info: [discovery] [iface:vEthernet (VPN Work 2FA):192.168.144.1] multicast recv socket is bound to 0.0.0.0:9003
05/27 10:39:37 Info: [discovery] [iface:vEthernet (VPN Work 2FA):192.168.144.1] multicast send socket is bound to 0.0.0.0:61629
05/27 10:39:37 Info: [discovery] unicast socket is bound to 0.0.0.0:9003
05/27 10:39:37 Trace: [raatmanager] starting server
05/27 10:39:37 Error: [jsonserver] uv_tcp_bind or uv_listen failed: permission denied
05/27 10:39:37 Error: [raatmanager] while starting json server: RNET__JSON_SERVER_STATUS_NETWORK_ERROR

vadim · June 2, 2026, 12:45pm

Hi @ISkIN,

Thank you for the logs — they point directly to the cause.

RAATServer is failing to bind to port 9004 on your machine with a permission denied error:

[jsonserver] uv_tcp_bind or uv_listen failed: permission denied
[raatmanager] while starting json server: RNET__JSON_SERVER_STATUS_NETWORK_ERROR

This means something on your Windows machine is blocking RAATServer from opening that port after waking from sleep. The most likely culprit is another process that has already claimed port 9004, or a network policy introduced by one of your VPN adapters.

We can also see several virtual network interfaces active at the same time (VPN Work 2FA, vEthernet Default Switch, vEthernet Ethernet), which can interfere with RAATServer’s ability to bind correctly on wake.

Please try the following:

Check what is holding port 9004 — open Command Prompt as Administrator and run:
```
netstat -ano | findstr :9004
```
Share the output here so we can see what process is occupying the port when the issue occurs.
Disconnect your VPN before waking from sleep and see if the problem still occurs — this will help us confirm whether the VPN adapters are the trigger.
Verify your .NET 10 installation — since Roon 2.65 migrated to .NET 10, please confirm it is correctly installed on your machine. Open Command Prompt and run:
```
dotnet --list-runtimes
```
and share the output. If .NET 10 is missing or corrupted, it can prevent RAATServer from starting properly. You can download the latest .NET 10 runtime from here.

Let us know what both commands show!

noris · June 8, 2026, 8:56pm

Hi @ISkIN,

Just checking in on this. Were you able to run netstat -ano | findstr :9004 as admin, try waking the machine with the VPN disconnected, and confirm whether dotnet --list-runtimes shows .NET 10 on the system? If you have the output from those commands, send it over and we can narrow down what is blocking RAATServer from binding to port 9004. Thanks.

ISkIN · June 9, 2026, 1:57pm

Oh, it’s just that the problem hasn’t happened again since then (it doesn’t happen that often), so I haven’t been able to check everything. I’m only attaching the output of the command “dotnet --list-runtimes”. As soon as the problem occurs again, I will be able to check the port.

dotnet --list-runtimes

Microsoft.AspNetCore.All 2.1.26 [c:\program files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.26 [c:\program files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.13 [c:\program files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.4 [c:\program files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.5 [c:\program files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.26 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.13 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.5 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.36 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.27 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.8 [c:\program files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.13 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.4 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.5 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.36 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.27 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.8 [c:\program files\dotnet\shared\Microsoft.WindowsDesktop.App]

vadim · June 12, 2026, 10:10am

Hello @ISkIN,

Thank you for running that command and sharing the output!

I can confirm that your .NET 10 runtimes (both the Core and Windows Desktop apps) are perfectly installed and up to date. This is great news because it completely rules out a corrupted software framework as the root cause.

Since the issue only happens intermittently, it is completely understandable that you haven’t been able to catch it in the act yet. There is absolutely no rush on our end. We will leave this thread open and monitor it.

The next time you wake your computer and notice the audio devices are missing, just grab that netstat -ano | findstr :9004 output before you restart any services or reboot the PC.

Take your time, and just drop a reply here whenever the issue pops back up. We will be right here ready to review it!

connor · June 17, 2026, 4:26pm

Hi @ISkIN,

If this is intermittent and you haven’t seen it since, there are a few plausible and largely harmless explanations, depending on what happened just prior to restarting RAAT.

In some cases, if Roon crashed or was forced closed, port 9004 won’t yet have been released from the prior instance.

How soon after rebooting the PC did Roon launch? If the child process hasn’t fully initialized its listen socket before that connect fires, the OS often refuses it, even on loopback. The process startup latency might have only been severe enough for this to occur in this single reboot instance.

Were you waking the PC from sleep at any point when this occurred? That might have a separate pathway.

In any case, let us know if this occurs again. Thank you!

noris · June 24, 2026, 2:38pm

Hello @ISkIN ,

We have not heard back from you, so we will go ahead and close this thread due to inactivity. If you need further assistance, please submit a reopen support request via the technical support help form link and specify that the issue be reopened. Thank you.

noris · July 1, 2026, 8:01pm

Hello @ISkIN ,

This thread has been reopened as per your request. Can you please let us know the latest status on this issue?

ISkIN · July 1, 2026, 8:52pm

Hello! The problem has happened again and I can finally share the result of the command. As you can see, no other application is listening on port 9004. I also checked it through System Informer. The gif shows how the RAATServer is trying to listen to this port, but for some reason it doesn’t work.

netstat -ano | findstr :9004

C:\WINDOWS\system32>netstat -ano | findstr :9004
TCP 127.0.0.1:2901 127.0.0.1:9004 SYN_SENT 5056

C:\WINDOWS\system32>netstat -ano | findstr :9004

C:\WINDOWS\system32>netstat -ano | findstr :9004
TCP 127.0.0.1:3129 127.0.0.1:9004 SYN_SENT 5056

C:\WINDOWS\system32>netstat -ano | findstr :9004

C:\WINDOWS\system32>

System Informer

RAATFail

Roon Log

07/01 12:23:40 Info: [raatserver] [runner] Start or Connect…
07/01 12:23:40 Info: [raatserver] [runner] Start or Connect… C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe
07/01 12:23:40 Info: ConnectOrStartAndWaitForExit RAATServer, path: C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe
07/01 12:23:40 Info: ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver
07/01 12:23:41 Info: [stats] 2234501mb Virtual, 407mb Physical, 95mb Managed, 312mb estimated Unmanaged, 1161 Handles, 40 Threads, 0.12% of runtime in GC pauses, 1ms last GC pause duration
07/01 12:23:41 Debug: threshold_minutes: 10080
07/01 12:23:42 Info: ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let’s start one
07/01 12:23:42 Info: [raatserver] [runner] Status: Started
07/01 12:23:50 Warn: exception starting raatserver: System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it. [::ffff:127.0.0.1]:9004
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.Net.Sockets.Socket.Connect(String host, Int32 port)
at System.Net.Sockets.TcpClient.Connect(String hostname, Int32 port)
at System.Net.Sockets.TcpClient..ctor(String hostname, Int32 port)
at Sooloos.RAATServer.ConnectOrStartAndWaitForExit(String path, String args, Action`1 status, ChildProcess& p) 07/01 12:23:52 Info: [raatserver] [runner] Start or Connect... 07/01 12:23:52 Info: [raatserver] [runner] Start or Connect... C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe 07/01 12:23:52 Info: ConnectOrStartAndWaitForExit RAATServer, path: C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe 07/01 12:23:52 Info: ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver 07/01 12:23:54 Info: ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let's start one 07/01 12:23:54 Info: [raatserver] [runner] Status: Started 07/01 12:23:56 Info: [stats] 2234503mb Virtual, 408mb Physical, 94mb Managed, 314mb estimated Unmanaged, 1165 Handles, 41 Threads, 0.12% of runtime in GC pauses, 1ms last GC pause duration 07/01 12:24:02 Warn: exception starting raatserver: System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it. [::ffff:127.0.0.1]:9004 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Connect(EndPoint remoteEP) at System.Net.Sockets.TcpClient..ctor(String hostname, Int32 port) at Sooloos.RAATServer.ConnectOrStartAndWaitForExit(String path, String args, Action`1 status, ChildProcess& p)
07/01 12:24:03 Info: [raatserver] [runner] Start or Connect…
07/01 12:24:03 Info: [raatserver] [runner] Start or Connect… C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe
07/01 12:24:03 Info: ConnectOrStartAndWaitForExit RAATServer, path: C:\Users\ISkIN\AppData\Local\Roon\Application\RAATServer.exe
07/01 12:24:03 Info: ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver
07/01 12:24:05 Info: ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let’s start one
07/01 12:24:05 Info: [raatserver] [runner] Status: Started
07/01 12:24:11 Info: [stats] 2234501mb Virtual, 406mb Physical, 92mb Managed, 314mb estimated Unmanaged, 1165 Handles, 40 Threads, 0.11% of runtime in GC pauses, 1ms last GC pause duration
07/01 12:24:11 Debug: threshold_minutes: 10080

RAATServer log

07/01 12:22:03 Info: Starting RAATServer v2.70 (build 1669) earlyaccess on windows
07/01 12:22:03 Info: Local time is 01-Jul-26 12:22:03 PM, UTC time is 01-Jul-26 9:22:03 AM
07/01 12:22:03 Trace: [bits] myinfo: {“os”:“Windows 10”,“platform”:“windows”,“machineversion”:207001669,“branch”:“earlyaccess”,“appmodifier”:“”,“appname”:“RAATServer”}
07/01 12:22:03 Debug: [easyhttp] [1] POST to ``https://bits.roonlabs.net/1/q/roon.base.,roon.internet_discovery.,roon.raatserver``. returned after 697 ms, status code: 200, request body size: 130 B
07/01 12:22:03 Trace: [bits] updated bits, in 721ms
07/01 12:22:03 Info: [RAATServer] creating RAAT__manager
07/01 12:22:03 Info: [RAATServer] appdata_dir = C:\Users\ISkIN\AppData\Local\RAATServer
07/01 12:22:03 Info: [RAATServer] unique_id = 35b05d98-aa4f-48ae-a3d1-e5bd7cad005a
07/01 12:22:03 Info: [RAATServer] machine_id = 07488255-4586-e728-9d3e-29b7b697ae61
07/01 12:22:03 Info: [RAATServer] machine_name = SUPERCOMPLUKTER
07/01 12:22:03 Info: [RAATServer] os_version = Windows 10
07/01 12:22:03 Info: [RAATServer] vendor =
07/01 12:22:03 Info: [RAATServer] model =
07/01 12:22:03 Info: [RAATServer] service_id = d7634b85-8190-470f-aa51-6cb5538dc1b9
07/01 12:22:03 Info: [RAATServer] is_dev = False
07/01 12:22:03 Trace: [raatmanager] starting
07/01 12:22:03 Info: [raatmanager] added codesigning key keypair_name=Roon public_key=9bb28e4e9e34ed4ff75c6a35339497cbdd3420713c941f5468571afc03555bf7
07/01 12:22:03 Trace: [raatmanager] [System Output] loaded config from C:\Users\ISkIN\AppData\Local\RAATServer\Settings\device_9b961fc2035f3dd343e04f8f136e7682.json
07/01 12:22:03 Trace: [raatmanager/windows] FOUND type=wasapi id={0.0.0.00000000}.{b61978ad-7e68-47e2-bd48-fc566a8876e5} usb_id=20b1:000a
07/01 12:22:03 Trace: [raatmanager/windows] name=XMOS XS1-U8 MFA output_name=Динамики
07/01 12:22:03 Trace: [raatmanager/windows] FOUND type=wasapi id={0.0.0.00000000}.{b70b23a7-c33d-4b81-b68e-a69458f14434} usb_id=
07/01 12:22:03 Trace: [raatmanager/windows] name=High Definition Audio Device output_name=Наушники
07/01 12:22:04 Trace: [raatmanager/windows] FOUND type=asio id={40F4F7C8-786F-49EB-8521-23CC5358D70E} usb_id=
07/01 12:22:04 Trace: [raatmanager/windows] name=TUSBAudio ASIO Driver output_name=
07/01 12:22:04 Trace: [raatmanager/windows] FOUND type=asio id={64083085-BD64-42AA-ADA3-73F51E17CAD7} usb_id=
07/01 12:22:04 Trace: [raatmanager/windows] name=XMOS USB Audio 2.0 ST 3085 output_name=
07/01 12:22:04 Trace: [raatmanager] [TUSBAudio ASIO Driver] loaded config from C:\Users\ISkIN\AppData\Local\RAATServer\Settings\device_c970e1eea47893c3cf8c1e31c8a5f514.json
07/01 12:22:04 Trace: [raatmanager] [XMOS USB Audio 2.0 ST 3085] loaded config from C:\Users\ISkIN\AppData\Local\RAATServer\Settings\device_5e315854e47d084264cd8195f66e7223.json
07/01 12:22:04 Trace: [raatmanager] initialized
07/01 12:22:04 Info: [RAATServer] running RAAT__manager
07/01 12:22:04 Warn: [raatmanager] update_bits, json string: {}
07/01 12:22:04 Trace: [raatmanager] starting discovery
07/01 12:22:04 Trace: [discovery] starting
07/01 12:22:04 Info: [discovery] [iface:VPN Work:172.30.255.104] multicast recv socket is bound to 0.0.0.0:9003
07/01 12:22:04 Info: [discovery] [iface:VPN Work:172.30.255.104] multicast send socket is bound to 0.0.0.0:60291
07/01 12:22:04 Info: [discovery] [iface:vEthernet (Ethernet):172.19.144.1] multicast recv socket is bound to 0.0.0.0:9003
07/01 12:22:04 Info: [discovery] [iface:vEthernet (Ethernet):172.19.144.1] multicast send socket is bound to 0.0.0.0:60292
07/01 12:22:04 Info: [discovery] [iface:vEthernet (Default Switch):172.26.16.1] multicast recv socket is bound to 0.0.0.0:9003
07/01 12:22:04 Info: [discovery] [iface:vEthernet (Default Switch):172.26.16.1] multicast send socket is bound to 0.0.0.0:60293
07/01 12:22:04 Info: [discovery] [iface:Ethernet:192.168.1.100] multicast recv socket is bound to 0.0.0.0:9003
07/01 12:22:04 Info: [discovery] [iface:Ethernet:192.168.1.100] multicast send socket is bound to 0.0.0.0:60294
07/01 12:22:04 Info: [discovery] [iface:Loopback Pseudo-Interface 1:127.0.0.1] multicast recv socket is bound to 0.0.0.0:9003
07/01 12:22:04 Info: [discovery] [iface:Loopback Pseudo-Interface 1:127.0.0.1] multicast send socket is bound to 0.0.0.0:60295
07/01 12:22:04 Info: [discovery] [iface:vEthernet (VPN Work):172.30.32.1] multicast recv socket is bound to 0.0.0.0:9003
07/01 12:22:04 Info: [discovery] [iface:vEthernet (VPN Work):172.30.32.1] multicast send socket is bound to 0.0.0.0:60296
07/01 12:22:04 Info: [discovery] [iface:vEthernet (WSL):172.23.128.1] multicast recv socket is bound to 0.0.0.0:9003
07/01 12:22:04 Info: [discovery] [iface:vEthernet (WSL):172.23.128.1] multicast send socket is bound to 0.0.0.0:60297
07/01 12:22:04 Info: [discovery] unicast socket is bound to 0.0.0.0:9003
07/01 12:22:04 Trace: [raatmanager] starting server
07/01 12:22:04 Error: [jsonserver] uv_tcp_bind or uv_listen failed: permission denied
07/01 12:22:04 Error: [raatmanager] while starting json server: RNET__JSON_SERVER_STATUS_NETWORK_ERROR

I also tried running another server (python, Flask) on the same port to check if the port is available, and it is available.

benjamin · July 2, 2026, 1:02am

Hey @ISkIN,

Thanks for sticking with this and for the netstat output, that was a helpful data point, since it confirms nothing else on the machine is holding port 9004 when the failure happens.

We went back through the Roon Server-side logs for your system (not just the client-side RAATServer log) covering the past few weeks, and we think we found the missing piece.

Your client machine’s RAATServer connection to the Server has actually dropped and failed to reconnect on at least 15 separate occasions since June 9th, this has been happening every 1-3 days, not as rarely as it seemed from the Remote side. In nearly every one of those events, the drop is immediately preceded by a failure from your USB DAC’s ASIO driver (TUSBAudio ASIO Driver), for example:


[raat_ll/client] [TUSBAudio ASIO Driver] no data received for &gt;10000ms. Killing connection.

[raat_ll/client] [TUSBAudio ASIO Driver] failed to connect(0) The I/O operation has been aborted...

[rnet/RnetJsonClient] ... "error_message": "DeviceOpenFailed" ... "name": "TUSBAudio ASIO Driver"

Right after that, the client disconnects from the Server entirely, and RAATServer’s local JSON control server appears to come back up in a bad state, which lines up with the “permission denied” binding error you’ve been seeing on port 9004. Our theory is that the socket isn’t being released cleanly after the ASIO failure, rather than something else actively blocking the port (which your netstat check already ruled out).

One notable episode on June 15th shows the ASIO driver failing to open the device roughly every 60 seconds for over 80 minutes straight, so the DAC was essentially unreachable to Roon for an extended stretch during that window.

Given this, we’d like to shift focus away from the VPN/.NET angle (which you’ve already ruled out) and onto the DAC/ASIO driver itself:

In Device Manager, open your DAC’s properties → Power Management tab, and uncheck “Allow the computer to turn off this device to save power,” if present.
Check whether any other application might be opening the DAC in exclusive ASIO mode around the times this occurs (a media player, DAW, or similar running in the background).
As a test, try setting up that zone via WASAPI instead of ASIO for a few days, if the drops stop, that would confirm the ASIO driver as the trigger rather than networking.
Check with your DAC’s manufacturer for an updated TUSBAudio ASIO driver version.

Could you give the WASAPI test a try and let us know if the disappearing-zones issue still occurs? That will help us confirm the ASIO driver as the root cause rather than the network stack.

Thanks again for your patience on this one!

ISkIN · July 3, 2026, 7:03pm

Thank you, I’ll try. However, I want to note that the problem described above occurred on July 1. It did not occur on June 15 or in those days; otherwise, I would have been able to send the command output earlier.

Regarding the USB DAC:

1. I don’t see the Power Management tab in the Device Manager for my usb dac
2. No application uses the DAC in exclusive mode (at least when the error occurs)
3-4. I updated the drivers for my DAC, and it seems that ASIO is not working / broken in the new version. Therefore, I’ll try WASAPI anyway.

benjamin · July 6, 2026, 6:45pm

Hi @ISkIN,

Thanks for the reply!

I was actually referring to the Windows Device Manager, not anything within Roon. Let me know if you’re able to take another look there.

We’ll be monitoring for your reply and results from testing out WASAPI in the meantime.

ISkIN · July 15, 2026, 5:28pm

Yes, I also meant Windows Device Manager. My DAC is displayed as the audio input “Headphones (usb dac)”, and there is no Power Management tab. Maybe I’m looking in the wrong place?

Now the problem has arisen again, even though I was using the DAC only in WASAPI mode. Honestly, I’m not at all sure that the problem is related to it. This time, everything was the same: I closed the running Roon Remote, and after a long time (and several times when the computer went to sleep), I launched Roon again, and it couldn’t find local audio devices – all the symptoms are the same as in the previous cases.

Windows Device Manager

connor · July 22, 2026, 9:11pm

Hi @ISkIN,

Thanks for your patience.

Hi @ISkIN,

Thanks for the very thorough diagnostics. The output you’ve shared confirm nothing else is using port 9004, which means Windows itself is blocking RAATServer from opening it.

This is almost certainly Hyper-V. Your machine runs several virtual network adapters. Hyper-V reserves blocks of ports for itself and re-picks them on every reboot and whenever the network re-initializes, such as waking from sleep or a VPN reconnecting. Most of the time 9004 is free and Roon works. Occasionally a reserved block lands on 9004 and Roon loses your audio devices. This is most likely why a reboot clears the issue.

Next time it happens, before rebooting, open Command Prompt and run:


netsh interface ipv4 show excludedportrange protocol=tcp

If 9004 falls inside any of the listed ranges, that is the cause. If it does not, let us know. That would point us somewhere else (likely one of the VPN network filters).

Reserve 9004 for Roon so Hyper-V stops taking it. Open Command Prompt as Administrator and run:


net stop winnat

netsh int ipv4 add excludedportrange protocol=tcp startport=9004 numberofports=1 store=persistent

net start winnat

Then run the first command again. You should now see 9004 in the list with an asterisk (*) next to it. That means it is reserved for Roon and Hyper-V can no longer take it. Reboot once and you should be set.

This is separate from the DAC, so no need to chase the audio driver. The port problem happens before the DAC is involved. Give it a try and let us know how it goes.

We’ll watch for your response.