RoonServer stability issue on AudioLinux causing network unresponsiveness (ref#3BLH2F)

[gameraider96]

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· The app is crashing

Please try to reboot your Roon Server

· Yes, rebooting helps, but the issue returns after some time

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?

· Issue happens on multiple remotes

Router Domain Name System (DNS) change

· I don't know how to do this

What is the operating system of your Roon Server host machine?

· Linux Server (Ubuntu, Fedora, ArchLinux...)

## Symptoms

· - Roon Core runs normally after boot; clients connect and playback works.
- After some time (often during idle), Roon disappears from remotes and the host may drop off the network.
- In many cases the machine becomes unreachable until a hard reboot (not just restarting Roon).

## Hardware / Network

· - Intel NUC-class system (11th-gen i3-1115G4, 16GB RAM)
- Intel I225-LM Ethernet (wired)
- Headless server, used only for Roon Core duties
- (I can provide exact OS/kernel and full system config)

## Software / Tuning already attempted

· To rule out tuning-related instability, I tested multiple configurations:
- RAM-root enabled/disabled (problem worse with RAM-root)
- CPU isolation disabled
- Realtime priority reverted to system default (“other” in AudioLinux realtime config)
- Different kernels (latest RT kernel vs recommended LTS kernel where possible)
- Network/USB power saving disabled
- BIOS power features adjusted (ASPM/S0ix/Modern Standby disabled; other settings toggled for stability)

Despite these changes, the issue persists intermittently.

## Request

· 1) Can you confirm whether this resembles a known Linux Roon Core issue (hang/crash/network dropouts) and whether it’s being tracked?
2) What logs would you like captured for diagnosis? I can provide:
- RoonServer logs from the Core at /opt/RoonServer (or the AudioLinux menu “systemd logs” view)
- system journal from the previous boot after a hang/reboot (kernel + systemd)
- timestamps of failure events and approximate uptime
3) If possible, please advise any recommended Roon Core settings/workarounds on Linux to reduce incidence (watchdog/keepalive, disable background tasks, etc.)

Thanks for your help — I’m happy to run any specific diagnostic steps you request to help reproduce and isolate this.

Best regards,
Cloud

Timestamp of issue occurrences

· NA

Describe the issue

Hi Roon Support,

I’m opening a ticket to report a repeatable stability issue when running Roon Core (RoonServer) on AudioLinux (Arch-based). The system will operate normally for some time, then Roon becomes unreachable and/or the entire machine becomes unresponsive on the network. Recovery requires a reboot. This happens most often when the system is idle (not actively playing).

AudioLinux support (Piero) believes this matches a known/previously reported Roon issue on Linux (not present on all installations) and recommended I open a new ticket so this can be investigated and patched.

Describe your network setup

Utopia Fiber (XMission) service. Fiber terminates at a DZS ONT (Zhone; model 2424GN). From the ONT I run into an ASUS RT-BE96U router (also acting as the main LAN distribution), then into a Netgear GS105 unmanaged switch feeding the Roon server and streamer chain (wired Ethernet; no Wi-Fi involved for the audio devices). No mesh/range extenders in the audio path. I’ve also been able to reproduce similar behavior in other homes/networks, so it doesn’t appear to be unique to this ISP or router.

[vadim]

Hello @gameraider96

Welcome to the community.

Thank you for providing such a detailed, well-structured, and thoroughly researched report. The extensive troubleshooting you have already performed—especially regarding power management, CPU isolation, and kernel tuning—gives us an excellent head start.

To address your questions directly:

1. Known Linux Issues While Piero from AudioLinux mentioned a known issue, your specific symptoms do not align with the bugs we are currently tracking. Right now, our engineering team is actively investigating two specific behaviors on Linux Cores:

• A memory leak over time.
• An inability to reconnect to an audio endpoint after that endpoint wakes up from standby or is powered back on (which currently requires a RoonServer restart to resolve).

Neither of these tracked issues causes the entire host machine to drop off the network or become completely unresponsive to the point of requiring a hard reboot. Typically, an application-level crash in Roon will not take down the host OS’s network stack unless there is an underlying kernel panic, a network driver hang (the Intel I225-LM controller does have a history of Linux driver quirks), or an aggressive OS-level power management state.

2. Gathering Logs We are more than happy to investigate this to see exactly what RoonServer was doing right before the system lockup. Please compile the logs you offered and upload them to our secure portal:

Upload Link: Roon Support Zoho Workdrive

Please include:

• The entire Logs folder from your RoonServer directory.
• The system journal (kernel + systemd) covering the timeframe of the failure.

Once you have uploaded the files, please reply here with a few specific timestamps (date and local time) of when the machine became unresponsive. This is crucial for us to align the system journal with the Roon logs and pinpoint the exact moment of failure.

Looking forward to taking a closer look at this with you!

[gameraider96]

Thanks for the detailed reply and guidance—very helpful.

Quick update: I believe I’ve identified and resolved the root cause. My AudioLinux configuration had the RoonServer application running with an overly aggressive realtime priority (RT 80). After returning RoonServer’s application priority to system default, the Core has been completely stable (including overnight idle periods) and I haven’t been able to reproduce the dropouts or host unresponsiveness.

Given the stability since that change, I don’t think further log collection is necessary at this time, but I’ll keep your instructions handy and can provide logs/timestamps if the behavior returns.