# RoonBridge 2.71 reproducible RAATServer issue on Raspberry Pi 2 with Volumio 4 (ref#CITWGW) **URL:** \ **Category:** Support\ **Tags:** rctt\_-06-2\ **Created:** [September 5, 2026, 2:15am UTC](https://community.roonlabs.com/t/roonbridge-2-71-reproducible-raatserver-issue-on-raspberry-pi-2-with-volumio-4-ref-citwgw/324605 "2026-09-05T02:15:23Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Helio\_Jesus](https://community.roonlabs.com/user_avatar/community.roonlabs.com/helio_jesus/32/335827_2.png) [@Helio\_Jesus](https://community.roonlabs.com/u/Helio_Jesus)\ **Post date:** [September 5, 2026, 2:15am UTC](https://community.roonlabs.com/t/roonbridge-2-71-reproducible-raatserver-issue-on-raspberry-pi-2-with-volumio-4-ref-citwgw/324605/1 "2026-09-05T02:15:23Z")
#### 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 · RoonBridge 2.71 build 1683 / .NET 10 – reproducible RAATServer startup/lifecycle issue on ARMv7 (Raspberry Pi 2 / Volumio 4) #### Tell us about your home network · Hello Roon Support, I would like to report a reproducible RoonBridge startup/lifecycle problem affecting RoonBridge 2.71 build 1683 on a Raspberry Pi 2 Model B running Volumio 4. I have investigated this in some depth and have a reproducible A/B test and a working systemd workaround. This does not appear to be the libicu/glibc installation problem that has also been reported for build 1683 on ARMv7. SYSTEM Hardware: Raspberry Pi 2 Model B rev 1.1 Revision code: a01041 CPU: ARMv7 / Cortex-A7, four cores Architecture: armv7l OS: Volumio 4.119 Debian Bookworm based Kernel: Linux 6.12.74-v7+ armv7l Runtime: glibc 2.36 OpenSSL 3.0.19 libicu72 installed Roon: RoonBridge 2.71 build 1683 Production linuxarmv7hf .NET 10 generation Audio device: OPPO USB Audio Device connected directly by USB Roon Server is on another machine on the same LAN. ROON COMPATIBILITY CHECKS Roon's supplied check.sh returns: Checking for a supported glibc version [OK] Checking for Binary Compatibility [OK] Checking for libstdc++ [OK] Checking for libicu [OK] Checking for ALSA Libraries [OK] STATUS: SUCCESS I also checked the RAATServer executable using ldd. All required libraries resolve successfully; there are no "not found" dependencies. ALSA is working correctly. aplay -l reports: card 5: Device [OPPO USB Audio Device], device 0: USB Audio [USB Audio] The corresponding ALSA playback device is available as: hw:CARD=Device,DEV=0 /dev/snd contains the expected control and playback devices. I also checked device contention. No other process was holding the OPPO PCM playback device. There were no relevant kernel messages indicating: - segmentation faults - illegal instructions - OOM kills - RAATServer crashes - USB audio failures FAILURE WITH NORMAL ROONBRIDGE STARTUP With the normal RoonBridge startup path, the Roon endpoint does not initially appear. RoonBridge repeatedly logs: ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver followed by: ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let's start one and then approximately several seconds later: System.Net.Sockets.SocketException (111): Connection refused [::ffff:127.0.0.1]:9004 followed by: Not Running (.o) The process then retries. Without intervention this previously resulted in an ongoing RAATServer startup/retry cycle and the endpoint was unavailable in Roon. RAATSERVER ITSELF WORKS I then stopped RoonBridge and launched the RAATServer executable directly, using the same Roon data environment: ROON\_DATAROOT=/data/configuration/music\_service/RoonBridge ROON\_ID\_DIR=/data/configuration/music\_service/RoonBridge Executable: /data/plugins/music\_service/RoonBridge/RoonBridge/Bridge/RAATServer This starts successfully. The RAAT log shows: Starting RAATServer v2.71 (build 1683) production on linuxarmv7hf detected ALSA support and correctly finds the USB DAC: FOUND id=hw:CARD=Device,DEV=0 vendor=OPPO name=OPPO USB Audio Device It then successfully: - initializes the RAAT manager - starts network discovery - opens the local/control server - listens on TCP 9200 - establishes the local RAAT control path - accepts a connection from the Roon Server - responds successfully to enumerate\_devices - exposes the OPPO USB Audio Device The direct/manual startup takes approximately seven seconds on this Raspberry Pi 2 before RAAT reaches its manager/server-ready state. A/B TEST The most useful test was the following. 1. Stop RoonBridge. 2. Start RAATServer manually. 3. Wait until TCP 127.0.0.1:9004 is listening. 4. Start RoonBridge. With RAATServer already ready, RoonBridge logs: ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver but does NOT immediately enter the previous failed-launch cycle. The Raspberry Pi then appears correctly in: Roon \> Settings \> Audio The OPPO USB Audio Device appears as a native ALSA device, can be enabled, and plays audio correctly via RAAT. This proves that: - the ARMv7 RAATServer binary works on this Pi - the current RoonBridge/RAAT binaries can run on this system - ALSA works - the OPPO USB interface works - LAN discovery and communication with Roon Server work - actual audio playback through Roon -\> RAAT -\> ALSA -\> OPPO works The failure therefore appears to be associated with startup/lifecycle coordination rather than basic binary compatibility. SYSTEMD WORKAROUND I created a separate RAATServer service: /etc/systemd/system/roon-raat-prestart.service Contents: [Unit] Description=Pre-start Roon RAATServer [Service] Type=simple Environment=ROON\_DATAROOT=/data/configuration/music\_service/RoonBridge Environment=ROON\_ID\_DIR=/data/configuration/music\_service/RoonBridge WorkingDirectory=/data/plugins/music\_service/RoonBridge/RoonBridge/Bridge ExecStart=/data/plugins/music\_service/RoonBridge/RoonBridge/Bridge/RAATServer Restart=always RestartSec=1 I then added a systemd drop-in for RoonBridge: /etc/systemd/system/roonbridge.service.d/raat-prestart.conf Contents: [Unit] Wants=roon-raat-prestart.service After=roon-raat-prestart.service [Service] ExecStartPre=/bin/systemctl restart roon-raat-prestart.service ExecStartPre=/bin/sh -c 'for i in $(seq 1 120); do ss -ltn | grep -q "127.0.0.1:9004" && exit 0; sleep 0.25; done; echo "RAATServer did not become ready on port 9004"; exit 1' The second ExecStartPre is deliberately state-based rather than a fixed delay: RoonBridge is released as soon as port 9004 becomes available, with 30 seconds merely acting as a maximum safety timeout. COLD-BOOT RESULT This workaround has now survived a complete Raspberry Pi reboot without any manual intervention. After boot: - RoonBridge is active - RAATServer is active - 127.0.0.1:9004 is listening - 0.0.0.0:9200 is listening - the Raspberry Pi endpoint appears automatically in Roon - the OPPO endpoint appears - audio playback works normally However, the cold-boot journal is particularly interesting. It still recorded: ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver then: ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let's start one and: System.Net.Sockets.SocketException (111): Connection refused [::ffff:127.0.0.1]:9004 before subsequently retrying and recovering. The separate RAAT service reported: NRestarts=1 After that single automatic restart, RAATServer remained continuously alive and stable. Several minutes after boot the processes were still running normally, including the same RAATServer PID, and playback remained stable. INTERPRETATION My current interpretation is therefore not that ARMv7 is fundamentally incompatible with RoonBridge 2.71. The hardware successfully runs the software and plays audio once the RoonBridge/RAATServer relationship becomes established. Rather, the evidence points to a startup/lifecycle race or timeout assumption between RoonBridge and RAATServer that becomes visible on relatively slow ARMv7 hardware. The migration of RoonBridge 2.71 build 1683 to .NET 10 is obviously correlated with when this problem appeared, but I cannot establish from the outside whether .NET 10 itself is the root cause. The important observation is that RoonBridge's ConnectOrStartAndWaitForExit() logic appears not to tolerate the actual RAATServer startup/lifecycle timings on this hardware. The independent systemd supervision converts what was previously an indefinite startup failure into: cold boot -\> initial RAAT/RoonBridge synchronization failure -\> one RAATServer restart -\> successful connection -\> stable operation and playback REQUEST Could you please investigate: 1. the startup timeout/retry behaviour in ConnectOrStartAndWaitForExit(); 2. RAATServer's approximately 20-second clean exit behaviour when the expected relationship with RoonBridge is not established; 3. whether the .NET 10 migration has increased startup latency sufficiently to expose an existing timing assumption on slower ARMv7 devices; 4. whether RoonBridge should wait for an explicit RAATServer-ready state rather than relying on a short fixed timing window; 5. whether ARMv7/Raspberry Pi 2 class hardware is still intended to be supported by build 1683. I would be happy to provide the complete RoonBridge and RAATServer logs, additional systemd journals, or reproduce the behaviour with the workaround removed if this would help engineering. I am also reporting the integration aspect to Volumio, since their RoonBridge plugin provides the systemd launch environment, but the failing 127.0.0.1:9004 handshake and ConnectOrStartAndWaitForExit() behaviour appear to be inside RoonBridge itself. Thank you. ---
**Author:** ![vadim](https://community.roonlabs.com/user_avatar/community.roonlabs.com/vadim/32/335515_2.png) [@vadim](https://community.roonlabs.com/u/vadim)\ **Post date:** [September 7, 2026, 10:44am UTC](https://community.roonlabs.com/t/roonbridge-2-71-reproducible-raatserver-issue-on-raspberry-pi-2-with-volumio-4-ref-citwgw/324605/2 "2026-09-07T10:44:02Z")
Hello @Helio_Jesus We’ve discussed this with our senior QA and development teams. The team is investigating some possibilities here and, as soon as that investigation is complete, we’ll be sure to follow up ASAP. You have our apologies for the trouble here, and we’ve greatly appreciated your patience as we continue investigating this tricky issue. We’ll be in touch as soon as we can. ---
**Author:** ![system](https://roon-community-uploads.s3.amazonaws.com/original/3X/d/e/deefbd9083c99c82bbf2dd3f873f52a49f5db881.png) [@system](https://community.roonlabs.com/u/system)\ **Post date:** [September 14, 2026, 10:45am UTC](https://community.roonlabs.com/t/roonbridge-2-71-reproducible-raatserver-issue-on-raspberry-pi-2-with-volumio-4-ref-citwgw/324605/3 "2026-09-14T10:45:00Z")
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.