Playback keeps stopping on HifiBerry due to multiple failures (ref#MPBGJ3)

Charles_Snider · May 21, 2026, 12:17am

What best describes your playback issue?

· The queue is skipping tracks

What type of Zone is affected by this problem?

· *Network Zones* are affected.

Does the issue affect all file formats?

· The issue *only affects one file *format.

Which format is giving you trouble?

· FLAC

Is your device connected directly to the Roon Server via cable or over the network, or is it chained through another device (such as a streamer, Roon Bridge, or Roon Remote)?

· It is connected through a different device (e.g Rasberry Pi)

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?

· now

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

· Hifiberry

Describe the issue

HifiBerry - too many failures, stopping playback

Describe your network setup

Wifi

Charles_Snider · May 21, 2026, 12:18am

All other WIRED devices are working correctly. Firewall is off. This appears to be either because of Wifi or ANDROID app.
Previously this has worked perfectly!

Charles_Snider · May 21, 2026, 9:58am

05/21 03:57:42 Warn: [raat_ll/client] [HiFiBerry DAC+ @ 192.168.0.35:33739] failed to connect(0) Connection refused
05/21 03:57:42 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] => ConnectionFailed
05/21 03:57:42 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] client connection failed. Retrying in 750ms
05/21 03:57:43 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] connecting (attempt 3)
05/21 03:57:43 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] => Connecting
05/21 03:57:43 Warn: [raat_ll/client] [HiFiBerry DAC+ @ 192.168.0.35:33739] failed to connect(0) Connection refused
05/21 03:57:43 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] => ConnectionFailed
05/21 03:57:43 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] client connection failed. Retrying in 1125ms
05/21 03:57:44 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] connecting (attempt 4)
05/21 03:57:44 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] => Connecting
05/21 03:57:44 Warn: [raat_ll/client] [HiFiBerry DAC+ @ 192.168.0.35:33739] failed to connect(0) Connection refused
05/21 03:57:44 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] => ConnectionFailed
05/21 03:57:44 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] client connection failed. Retrying in 1687ms
05/21 03:57:46 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] connecting (attempt 5)
05/21 03:57:46 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] => Connecting
05/21 03:57:46 Warn: [raat_ll/client] [HiFiBerry DAC+ @ 192.168.0.35:33739] failed to connect(0) Connection refused
05/21 03:57:46 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] => ConnectionFailed
05/21 03:57:46 Trace: [raat] [HiFiBerry DAC+ @ 192.168.0.35:33739] client connection failed. Giving up

vadim · May 21, 2026, 12:00pm

Hello @Charles_Snider,

Thank you for providing those log snippets! They are incredibly helpful and point us directly to the root of the problem.

The logs show a repeated Connection refused error when your Roon Server tries to send the audio stream to the HiFiBerry at IP address 192.168.0.35. In networking, a “connection refused” error is very specific: it means the Roon Server is successfully reaching a device at that IP address, but the device is actively rejecting the connection because the Roon playback service (RAAT/RoonBridge) is either not running or not listening on that port.

Because your other wired devices are working perfectly, this points to a few specific possibilities with the HiFiBerry setup itself. Here are the best next steps to get this resolved:

1. Reboot the HiFiBerry

Sometimes, the background RoonBridge software on the Raspberry Pi simply crashes while the underlying operating system stays online. Unplug the power from the HiFiBerry, wait 10 seconds, and plug it back in. This will force the RAAT service to start completely fresh.

2. Check for an IP Conflict

Wi-Fi devices routinely disconnect and reconnect, meaning your router may have reassigned 192.168.0.35 to a different device on your network (like a phone or smart plug). Roon is trying to send music to that IP, and the new device is refusing it because it isn’t an audio player.

To fix this, log into your router and set a Static IP (or DHCP Reservation) for the HiFiBerry so its address never changes.

3. Check the Endpoint Software Version

If a reboot and IP check do not bring the RAAT service back online, the software running on your HiFiBerry might be outdated or corrupted.

Depending on what operating system you are using on the Raspberry Pi (such as HiFiBerryOS, RoPieee, or DietPi), log into the device’s web interface and ensure the system software is fully updated to the latest version.
If it is already fully updated but still refusing the connection, re-flashing the SD card with a fresh installation is the best way to repair the corrupted RoonBridge service.

Give these steps a try, and let us know what the results are!

Charles_Snider · May 22, 2026, 1:32pm

Hi. I did fix the IP address. Here is ping result from the Roon Core Server (Linux) computer:
roon@desktop:~$ ping 192.168.0.35
PING 192.168.0.35 (192.168.0.35) 56(84) bytes of data.
64 bytes from 192.168.0.35: icmp_seq=1 ttl=64 time=6.75 ms
64 bytes from 192.168.0.35: icmp_seq=2 ttl=64 time=6.65 ms
64 bytes from 192.168.0.35: icmp_seq=3 ttl=64 time=6.82 ms
64 bytes from 192.168.0.35: icmp_seq=4 ttl=64 time=6.83 ms
64 bytes from 192.168.0.35: icmp_seq=5 ttl=64 time=6.85 ms
— 192.168.0.35 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 6.654/6.779/6.846/0.071 ms
It’s running the new HifiBerry OS “hbosng” and works fine with a wired connection, so I think we can rule out the device.

I do have an issue with Android Roon app. When I turn the UFW on, it’ cannot find the server. I have the recommend “Roon” UFW rules, and again, it’s been running fine for many years.

I have a NetGear Orbi Mesh router.

Thank you

Charles_Snider · May 22, 2026, 2:49pm

I can post logs if that helps further.

UFW Rules:

[Roon]
title=Roon Server
description=Roon Labs Core Music Server
ports=1194,9003/udp|8008:8009,9330:9339,30000:30010/tcp

Roon ALLOW 192.168.0.0/24
40229/tcp ALLOW Anywhere # roonarc

Note that wired endpoints work fine, Roon Arc works without issue. Hifiberry on wifi will play fine from wired Windows Roon app. All is with UFW enabled.

Problem is

Android app cannot find server with Firewall on.
Roon app on Windows cannot find server with Firewall on.
Hifiberry will not playback over wifi from Android app or Windows app with firewall off.

So clearly there’s something going on with Wifi and UFW.

Charles_Snider · May 23, 2026, 8:33am

Charles_Snider · May 27, 2026, 1:08pm

@vadim Please reply. Thank you

Charles_Snider · May 29, 2026, 7:35pm

@vadim Please reply thank you.

benjamin · June 2, 2026, 7:50pm

Hi @Charles_Snider,

Thanks for the screenshots and additional information! Based on a fresh Roon Server diagnostic report, it does appear that UFW Is Blocking RAAT’s Dynamic UDP Clock Sync Ports.

Every failure looks like this:

GOT {"audio_port_tcp":35925, "clock_port":35590, ...} ← RAAT negotiates ports
failed to sync sender clock to endpointHiFiBerry DAC+ ← UDP reply is blocked
failed to sync clocks with any endpoints..giving up ← gives up, stops playback

The TCP connection succeeds (it’s initiated outbound from the server to the HiFiBerry, so UFW allows it). But the UDP clock sync reply from the HiFiBerry back to the server is blocked because those ports are random and not in your UFW rules.

Why wired endpoints work: Your wired Ropieee and Lumin T3X likely either have specific ALLOW rules, or wired traffic is on a trusted interface (e.g. ufw allow in on eth0), while WiFi traffic comes in on wlan0 or a separate interface that doesn’t have that implicit trust.

Why playback from wired Windows app to HiFiBerry over WiFi fails: The issue isn’t the control source (Windows app). It’s that the HiFiBerry itself is on WiFi and its UDP clock sync packets to the Roon Server are blocked regardless of what initiates playback.

Let’s see if the following may help:

Allow all traffic from the HiFiBerry’s IP:

sudo ufw allow from 192.168.0.35

With that, your rules may be missing UDP port 9003 for SOOD (Roon’s discovery protocol) from WiFi clients. Your current rule may only have 9003/udp in the named Roon profile but Android and Windows clients on WiFi may be hitting the ufw default deny on the interface. Try:

sudo ufw allow from 192.168.0.0/24 to any port 9003 proto udp
sudo ufw allow from 192.168.0.0/24 to any port 9100:9200 proto tcp # Roon control

If neither help, while reproducing the failure, run this on the Roon Server to watch what UFW is actually blocking:

sudo ufw logging on
sudo tail -f /var/log/ufw.log | grep "192.168.0.35"

You should see [UFW BLOCK] entries for UDP packets from 192.168.0.35 on random high ports, that should confirm the issue.

We’ll be monitoring for your reply and results, thank you!

Charles_Snider · June 3, 2026, 7:50pm

Here’s is this:
sudo ufw status numbered
Status: active

 To                         Action      From
 --                         ------      ----

[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 8010 ALLOW IN Anywhere # chromecast
[ 3] Roon ALLOW IN 192.168.0.0/24
[ 4] 40229/tcp ALLOW IN Anywhere # roonarc
[ 5] 8200/tcp ALLOW IN Anywhere # minidlna
[ 6] 1900/udp ALLOW IN Anywhere # minidlna
[ 7] 58051/tcp ALLOW IN Anywhere # bubblesoft
[ 8] 58050/tcp ALLOW IN Anywhere # bubblesoft
[ 9] Anywhere ALLOW IN 192.168.0.35
[10] 9003/udp ALLOW IN 192.168.0.0/24
[11] 9100:9200/tcp ALLOW IN 192.168.0.0/24

With UFW on, roon apps on Wifi cannpt find the Roon Server.
With UFW off, roon apps on Wifi find the Roon Server, but when played to the Hifiberry “Too Many Failures. Stopping Playback” both Wifi and Wired.

benjamin · June 4, 2026, 10:28pm

Hi @Charles_Snider,

Thanks for the update. Can you confirm, with UFW completely disabled, if you SSH into the HifiBerry and run iwconfig wlan0, what does the Power Management line say?

Charles_Snider · June 5, 2026, 7:25pm

Hi Benjamin
After much thought and some ChatGPT I found the issue. It is a bug in the Netgear Orbi Router. The DMZ defaulted to 192.168.0.0 instead of the IP I entered. I disabled DMZ and everything Roon Wifi started to work as expected. I am using port forwarding instead of DMZ now, which is probably better.
The good news is also that the UFW profile I use is just fine, works 100%.
Thanks for your help.

Just FYI, DMZ with UFW is not that different than Port Forwarding.

vadim · June 8, 2026, 6:48am

Hello @Charles_Snider,

Glad you tracked it down! Just to note — while DMZ can seem like a quick fix for connectivity issues, it is generally not recommended for a home network as it exposes the device completely to the internet with no firewall protection. Port forwarding is the correct and safer approach, as it only opens the specific ports that are needed. Good call making the switch!