Roon Bridge 'Device not found' error on Debian 13 armhf (ref#5C8TWM)

[YuiFunami]

What best describes your playback issue?

· A connected audio device is not appearing in Roon

What type of Zone is affected by this problem?

· *Network Zones* are affected.

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?

· Yes, it shows up there, but it isn't Enabled

Does the "Enable" button unlock the Zone?

· I pressed Enable, but the Zone remains disabled

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

Since you are using a network connection to the device, please ensure that your RoonServer is on the same subnet as the device

· My devices are on a single subnet but is not visible to Roon

Do you have a complex network setup?

· Both the device and RoonServer are connecting to a *single router*

Try to disable any additional networking interfaces on your RoonServer machine.

· Disabling network interfaces had no change in behavior

Check to make sure RoonReady mode is selected on the device.

· I've checked this 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

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

· Gustard R26's internal streamer running Roon Bridge on Debian 13 armhf

Describe the issue

Roon Bridge cannot enable device on Debian 13 armhf (armv7l) with "Device not found" error, likely due to different ABI used on Debian 13 to solve the Year 2038 Problem (see https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#bit-time-t-abi-transition and https://wiki.debian.org/ReleaseGoals/64bit-time).

Describe your network setup

Just a router

[YuiFunami]

Do note that downgrading my streamer to Debian 12 does make it work perfectly again, writing this just to shoo away the comments about my unusual setup using Roon on Docker on VM running RHEL on Proxmox VE.

[vadim]

Hi @YuiFunami,

That is a very specific and interesting hypothesis regarding the Debian 13 ABI transition and the Year 2038 problem.

Before we go down the rabbit hole of investigating ABI incompatibilities, we need to establish a stable baseline to rule out more common causes:

1. Can you please confirm that both the Roon Bridge on the Gustard and your Roon Server are running the latest Production 2.60 builds?

2. We recall from your previous ticket that your Roon Server is running in a virtualized/Docker environment. Have you been able to test this specific Debian 13 Bridge against a non-virtualized Roon Core (e.g., a standard Windows or macOS install) on the same network?

We need to be absolutely sure that this isn’t a network isolation/multicast issue (common in VM setups) before we start looking into OS-level library mismatches.

[YuiFunami]

1. Yes.
2. I installed temporary Roon Server on my laptop running Arch Linux, can reproduce the issue.

Also log from RAATServer on the streamer:

09/03 18:46:19 Trace: [RAAT::Gustard USB Audio 2.0] [info] initializing info dictionary
09/03 18:46:19 Trace: [RAAT::Gustard USB Audio 2.0] [info] inserting raat_version -> 1.1.47
09/03 18:46:19 Trace: [RAAT::Gustard USB Audio 2.0] [info] inserting protocol_version -> 3
09/03 18:46:19 Info: [RAAT::Gustard USB Audio 2.0] [device] added codesigning key keypair_name=Roon public_key=CENSORED
09/03 18:46:19 Error: [raat_wrap] RAAT__OUTPUT_PLUGIN_STATUS_DEVICE_OPEN_FAILED failed: failed to initialize alsa output
09/03 18:46:19 Trace: [jsonserver] [CENSORED:38014] SENT [1] [nonfinal] {"device": {"vendor": "Gustard", "error_message": "DeviceOpenFailed", "type": "alsa", "device_id": "hw:CARD=G20,DEV=0", "name": "Gustard USB Audio 2.0", "config": {"unique_id": "CENSORED
09/03 18:46:19 Trace: [jsonserver] [CENSORED:38014] SENT [3] {"status": "DeviceEnableFailed", "error": "RAAT__OUTPUT_PLUGIN_STATUS_DEVICE_OPEN_FAILED"}

[vadim]

Hello @YuiFunami

I attempted to reproduce this on a Debian 13 test setup on my end, and RoonBridge initialized correctly, but this may depend on the specific package snapshot in “Trixie” currently installed.

I wanted to take a deeper look at your logs to confirm the ABI mismatch, but I hit a snag: the timestamp you shared seems to be 09/03. Since we are currently in February, the system interprets this as March 9th, which hasn’t happened yet.

If you are willing to test Debian 13 again:

1. Could you check the system date/time on the host and endpoint machines to ensure it’s synced?

2. Please generate a fresh log set and let me know the exact timestamp of the failure.

For now, sticking to Debian 12 is definitely the stable choice.

[YuiFunami]

It’s no problem for all other architectures except armhf/armel since other architectures are already using 64bit time_t (and for the case of i386, which is the only exception, they didn’t transition for compatibility’s sake since its only purpose starting from Debian 13 is for running legacy software) so it would work on your AMD64 system just fine. This ABI change only happened on armhf and armel only.

So to reproduce this issue you NEED device running Debian 13 armhf or armel (e.g. RPi1, early RPi2 with ARMv7 SoC, RPi Zero, or Zero W) (later RPi2s have newer SoC with ARMv8 cores).

BTW I did test it before with the time synced correctly, the issue was still there.

[vadim]

Hello @YuiFunami

I do not have the arm device to test, so 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.

[YuiFunami]

Also double-checked Debian wiki for affected packages, and as expected alsa-lib is one of them so it’s likely that this ABI change is the cause.

[benjamin]

Thanks for the info @YuiFunami, we’ll be in touch as soon as our team is able to take a closer look.

Thank you!

[YuiFunami]

bump to prevent auto closure.

[vadim]

Hello @YuiFunami

Thank you for your interest. You don’t need to bump the thread. When our QA team finishes the testing, we will reopen it to provide the updates.