· Aurender N150 (Roon Ready) disappears from Roon after sample rate change – requires N150 reboot
Setup: Roon Core on NUC (ROCK), wired Ethernet. Endpoint: Aurender N150 (Roon Ready, latest firmware) → USB → Chord Hugo TT2. Network: router → SOtM sNH-10G switch → fiber media converter → N150.
Issue: Intermittently, the N150 disappears entirely from Roon's audio device list (not just disabled). Restarting Roon Server does not bring it back; only rebooting the N150 does. During the failure, the N150 is still reachable via Aurender's Conductor app, so the network path appears fine.
Log evidence (Roon Server logs, [date] 17:36:48): Immediately after a sample rate change from 44.1kHz to 192kHz, the N150's audio port reports "Broken pipe" and "Connection reset", followed by "Connection refused" on control port 43525. This suggests the RAAT service on the N150 stops at the sample-rate transition.
Already ruled out: IP conflict (fixed with DHCP reservations), Roon Core hardware (replaced; issue persists), Core location, LAN filter, router power cycle (per Aurender support).
Aurender support advised me to contact Roon. Could you review the logs around the failure time and advise whether this is a RAAT issue on the endpoint side?
Tell us about your home network
· Router: [공유기 제조사/모델명] (ISP-provided, 172.30.1.x subnet), located in the living room. No VPN, no mesh, no Wi-Fi extenders.
Roon Core: Intel NUC running ROCK, wired directly to the router by Ethernet. DHCP reservation (static IP).
Path to the endpoint (listening room): Router -> Cat6 copper (long run) -> TP-Link MC220L fiber media converter (powered by iFi iPower X) -> single-mode fiber (Finisar FTLF1318P3BTL SFPs) -> SOtM sNH-10G audio switch -> Aurender N150 (Roon Ready, wired Ethernet, DHCP reservation) -> USB -> Chord Hugo TT2.
A PC and a Synology NAS are also connected to the sNH-10G. All devices are on the same subnet. Multicast/IGMP settings on the router are default.
Previously found and fixed an IP conflict between the Roon Core and the PC; the N150 dropout still occurs afterwards.
Logs show TCP disconnections occurring outside of sample rate changes with this same endpoint. We’ll need to request that you simplify the network path here so we capture a clean reproduction event and precisely capture the order of events. The SOtM switch will be performing traffic optimization and other L3 activities.
At your convenience, please hardwire the Aurendar directly to the main router or access point serving Roon Server, bypassing any managed network components in the pathway. Then reproduce the problem once more. Our team will gather logs and promptly respond with what we see.
I’ll set up the test as you suggested. The Aurender N150 will be connected directly to the main router with a single Ethernet cable, with the SOtM switch and the fiber media converter removed from the path. The Roon Server (NUC running ROCK) is already wired directly to the same router, so both the Core and the endpoint will be on the router with no other network devices in between.
A couple of notes about the test conditions:
My PC and NAS are connected behind the SOtM switch, so they will be offline during the test. I’ll control playback with the Roon Remote app on my phone (and on my PC over Wi-Fi). Only the remotes will be on Wi-Fi; the Core and the N150 will remain wired.
Because the NAS will be unavailable, I’ll play music from streaming services (TIDAL/Qobuz) only.
Please let me know if these conditions are acceptable for your diagnosis. I’ll keep it playing for long sessions and will reply here with the exact date and time as soon as the dropout reoccurs.
Thank you for setting up the test. The conditions you describe work for us: the Core and the N150 wired directly to the router, remotes on Wi-Fi, and streaming only.
Please let us know whether the N150 dropped out at all in this setup. If it did, please include the date, time and time zone, whether the N150 disappeared from the device list again, and what was playing. Including some tracks that change the sample rate, for example from 44.1 kHz to 192 kHz as in the original event, will help us compare. If there are no dropouts after a long session, please tell us that as well.
