Frequent track skipping and 'too many failures' error with Sonore opticalRendu (ref#8HB1F6)

Support
1

What best describes your playback issue?

· The queue is skipping tracks

What type of Zone is affected by this problem?

· *All of my Zones* are affected.

Does the issue affect all file formats?

· The issue affects *multiple/all* file formats.

Does the issue happen with local library music, streaming service music, or both?

· *Both streaming and local* *library* music are affected.

Do you encounter any playback errors with the "System Output" Zone?

· The System Output has *no problem*, it's only my other Zone.

How is the affected Zone connected to your RoonServer machine?

· Network - Ethernet

Which network audio protocol is the Zone using with Roon?

· RoonReady

Does the device show up at all in Roon Settings -> Audio?

· The Zone is listed under the wrong protocol

Does the device play audio from another source when using the same connection?

· The device has no problems with another audio source

Have you checked that Roon is whitelisted in any firewalls?

· I've checked the firewall and the issue remains

If the device has multiple output options, do the other options work as expected?

· Only one output type is affected while the other output type works as expected

Is the device using the latest firmware as per the manufacturer?

· Firmware is up-to-date but the issue remains

Do you have an approximate timestamp of when the issue last occurred?

· Yes iwas trying to listen last night, repeatedly failed wirh this error (until I had to give up) possibly around midnight, repeatedly trying to listen to paloma paris album cacophony through tidal on roon

What are the make and model of the affected audio device(s) and the connection type?

· Sonore optical rendu / optical module

Describe the issue

Your flowchart doesnt work. Item 6 did not how the option "device shows up on correct protocol and is enabled". Anyhow my sonore opticalrendu / opticalmodule regularly struggles with the "too many failures" error message and skipping tracks until it gives up. It is connected via usb to astell and kern acro ca1000t dac (which works faultlessly as its own roon end point). The opticalmodule is connected via ethernet, not wireless. The problem only occurs on the opticalrendu, none of my other devices/end points, Resetting everything sometimes works to fix the problem, sometimes it doesnt. For a log, see me trying repeatedly to play music and failing approximately 9 hours ago from now (around 1130pm, brisbane time 30th may). This problem is persistent, occurs regularly, and stops me using roon entirely on the opticalrendu setup. The sonore software has been updated. Please advise.

Describe your network setup

See previous, opticalmodule on ethernet, feeding opticalrendu via optical cable, which then feeds astell and kern ca1000t dac via usb

2

Hi @john_smith3

Thank you for the detailed report and for providing the logs — they’ve been very helpful in narrowing down the cause.

After reviewing your logs, we can see a clear and recurring pattern: your local RAAT server (the audio transport component that runs alongside RoonServer on your Windows PC) is crashing repeatedly, and this is what’s causing the “too many failures” error and track skipping on the opticalRendu.

Here’s what we see in the logs around each failure:

exception starting raatserver: System.IO.IOException: Unable to read data from 
the transport connection: An existing connection was forcibly closed by the 
remote host.

When the RAAT server process dies, all active zones lose their connection simultaneously — which is why both your opticalRendu and other endpoints are affected at the same time. The “too many failures” message is Roon giving up on retrying after the RAAT crash. A reboot or restart sometimes helps temporarily because it starts a fresh RAAT process, but the underlying crash condition keeps recurring.

Your machine specs (32 GB RAM, Windows 11, Intel i7) rule out memory pressure as a factor — there’s plenty of headroom there.

To find the root cause of the RAAT server crash, we need you to check the following on your Windows machine:

1. Windows Event Viewer After the next time it happens (or retrospectively if it already has), please check:

  • Open Event Viewer → Windows Logs → Application
  • Filter for errors around the time of the crash (around midnight Brisbane time on May 30, and any subsequent occurrences)
  • Look for entries from source RAATServer, .NET Runtime, Application Error, or Windows Error Reporting
  • Also check Windows Logs → System for any critical errors at the same time

2. Antivirus / Security software Security software is the most common cause of this specific error (“connection forcibly closed by remote host” on a localhost socket). It can intercept or terminate the TCP connection between RoonServer and the RAATServer process. Please:

  • Check if you have any antivirus, endpoint protection, or internet security software running (Windows Defender, Malwarebytes, Norton, ESET, etc.)
  • Temporarily add exclusions for the Roon and RAAT executable folders:
    • C:\Users\Admin\AppData\Local\RoonServer\
    • C:\Users\Admin\AppData\Local\RAATServer\
  • If you have a third-party firewall (not Windows Firewall), check its logs for blocked connections around the crash times

3. VPN or network filtering software VPN clients, DNS filters (Pi-hole, NextDNS, etc.), or traffic inspection tools can also interfere with localhost connections. If you have any of these running, please try disabling them temporarily to test.

4. Windows Firewall Check that RAATServer.exe and RoonAppliance.exe are allowed through Windows Firewall (both private and public profiles):

  • Open Windows Defender Firewall → Allow an app through firewall
  • Confirm both Roon executables are listed and ticked

If you can share any relevant Event Viewer entries (especially Application Errors or .NET Runtime crashes around the incident times), that will help us identify exactly what is terminating the RAAT server process.

Thanks for your patience — we’re confident this is solvable once we identify what’s interfering with the RAAT server on your Windows machine.

3

Hi have followed advice for firewall exceptions and anti-virus exclusions.

There are lots of errors in events viewer. The most relevant(?) seem to be:

1000016605
10000166051920×2560 1.31 MB

1000016604
10000166041920×2560 1010 KB

1000016603
10000166031920×2560 1.38 MB

These are two photos of the same error (scrolled to allow viewing all the files attached, I have tried to click These but do not have permission to see them), and then a roon specific error. Thanks for your advice

4

Bump as no response

5

Hey @john_smith3,

Thanks for sending over a few screenshots! From them, we can see a few things:

  • Event Name: LiveKernelEvent: this means Windows detected a kernel-level problem while the system was still running (not a full crash/BSOD). It's a "live dump" captured because something went seriously wrong.
  • P1: 144: this is the bug check code. Code 144 corresponds to BUGCODE_USB_DRIVER, which points to a USB driver fault.
  • P2: 1009: a secondary parameter associated with the USB error type.
  • P3: ffffb4838afaf710: a kernel address, pointing to the specific driver object that faulted.
  • P6: 10_0_26200: confirms Windows 11 build 26200.
What this means for you: The LiveKernelEvent with USBXHCI strongly suggests your USB host controller or USB driver is faulting, likely triggered when Roon/RAAT is actively streaming audio over USB to your Astell & Kern CA1000T DAC.

This kernel fault would forcibly kill any active connections, including the RAAT server’s
http://localhost
socket, which matches exactly the “connection forcibly closed by remote host” error.

So, for next steps: Let’s first address the USB driver crash.

  1. Open Device Manager → expand Universal Serial Bus controllers → right-click your USB xHCI Host Controller → Update driver
  2. If that doesn't help, try uninstalling the driver (check "delete driver software") and letting Windows reinstall it fresh on reboot
  3. Check Windows Update. There may be a firmware or driver update for your motherboard's USB controller
  4. Try connecting the CA1000T DAC to a different USB port (ideally a USB 2.0 port if you have one, or a port on a different controller)
  5. Check the DAC manufacturer's site for a USB driver update for the CA1000T
With that, I’d also ensure Roon and RoonAppliance are excluded from any SSL inspection done by security software (some antivirus products intercept TLS traffic, which would cause exactly the Event 36874, Schannel: TLS 1.3 cipher suite mismatch.)

I hope this helps! We’ll be monitoring for your reply and results :+1: