Is the affected network Zone connected with Ethernet or WiFi?
· Ethernet
Does the issue affect all file formats?
· The issue affects *multiple/all* file formats.
Does the issue happen with local library music, streaming service music, or both?
· *Both streaming and local* *library* music are affected.
Do you encounter any playback errors with the "System Output" Zone?
· The System Output has *no problem*, it's only my other Zone.
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
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?
· yes. happens always. Roon appears to try to play the first 5 tracks and then returns the error.
What are the make and model of the affected audio device(s) and the connection type?
· see previous answer
Describe the issue
"Too many failures. Stopping playback." error after last Roon SW update on one zone only
Describe your network setup
Roon server on Mac Studio that is Ethernet-connected to network router. 5 endpoints: Audio interface plugged into Mac Studio via USB (works); the other 4 connected via Ethernet to router: 2 Apple AirPort Express units, 2 RoPieee Raspberry Pi units (only 1 has this problem). Roon sees the problem unit allows it to be enabled and disabled, but changes its icon. In one case, the icon is different in the zone picker than in "Audio" under settings
This problem occurred after the latest update was executed. That update caused Roon on the Mac Studio to fail with error report pop up. Roon has been restarted, the Mac Studio restarted, etc.
Also note some of the canned questions in this form don’t have answers that match problem or an “other” box.
Last night I executed a Roon SW update and all hell broke loose. Roon quit unexpectedly as a result of the update. Once restarted, one one endpoint I am getting same message “Too many failures. Stopping playback”. The icon on that endpoint changed, it is now different in the zone chooser vs. “Audio” tab of “Settings.” If a group of zones is set up, hitting pause causes the track to advance. This is so far the tip of the iceberg. My bet is that the follow on release to last weeks “big” update is an unmitigated disaster.
Since you’re running macOS, the behavior you’re seeing is consistent with the newer, stricter Local Network permission controls in the recent macOS releases.
Please try the following steps:
Open macOS System Settings → Privacy & Security → Local Network
Make sure Roon and Roon Server are both enabled
Even if they are already enabled, please toggle them off and back on
Fully quit Roon Server from the macOS menu bar / task bar
Reboot your Mac
After reboot, launch Roon again and check if the devices is avaliable again.
Can you try clearing your endpoint cache? You can do so using the following steps:
@vadim I tried both procedures, neither helped. The initial (enumerated) procedure I tried twice, first in the order you specified, then with Roon/server not open initially.
After deleting the endpoint_ files, I opened Roon and the 6 endpoint device names were blank so I simply renamed them. I tried playing a playlist on each device, the Mac Studio indicated that for each except “Ropieee Den” the initial song played. The song could be heard via the device connected to the Mac Studio.
If you are able to look into the machine, a correctly playing device started at 07:58 EDT and the problem “Ropieee Den” started at 07:59 EDT.
Keep in mind this problem only occurred after the latest Roon SW update. Once I noticed the problem I checked the 3 Raspberry PI endpoints, and updated their RoPieee SW as well.
The Ropieee Den zone is configured to output to the Benchmark DAC2 USB Audio 1.0 endpoint (connected to your Den RoPieee Pi). Every single playback attempt fails immediately with:
RAAT__OUTPUT_PLUGIN_STATUS_FORMAT_NOT_SUPPORTED
Roon sends a setup request to that endpoint, the endpoint rejects every format it tries, 96kHz/24bit, 44.1kHz/24bit, 48kHz/24bit, even 44.1kHz/16bit, and then gives up: failed to setup any endpoints..giving up.
The DAC physically supports those formats, as reported at startup, so theres no issues there. Let’s see if any of the following help:
1. Power-cycle the Den RoPieee Pi completely (unplug power, not just reboot) and also unplug/replug the USB cable to the DAC. The goal is to force the ALSA USB driver to reinitialize cleanly. A soft reboot may not clear the stuck driver state.
2. Swap the USB cable on the Den Pi → DAC connection. The “USB Audio 1.0 / Full Speed” designation strongly suggests the cable or port is degraded and not negotiating Hi-Speed USB properly. Try a different USB cable and see if there’s any difference.
3. Check the USB port on the Den Pi — try plugging the DAC into a different USB port on that Pi.
4. Check RoPieee’s device page for Den — in the RoPieee web UI for that Pi, see if the DAC is showing as USB 1.1/Full Speed vs USB 2.0/High Speed. The working LR Pi’s DAC explicitly shows as high speed.
@benjamin I am "eating crow” regarding my assumption that the latest Roon software update caused this issue. I had just updated the FPGA EPROM in both the Benchmark DAC2 L and DAC3 HGC before swapping their locations. Roon prompted me for the SW update which I ran before verifying operation of the updated DACs with ROON.
It turns out the DAC2 lost the previous USB 2.0 setting and reverted to USB 1.1, the DAC3 held the USB 2.0 setting. Once the DAC2 was reset to USB 2.0, this problem was fixed.
There were other issues after the update: the update caused the Roon server to crash, there was a dropout on a radio broadcast not recovered (the update was supposed to improve this), and the local Mac Studio audio device options disappeared in the “Settings > Audio” tab- recovered via restart or Studio reboot, forget which. I’ll keep an eye on these.
Roon support has improved notably with the addition of trouble tickets. I also appreciate the complexity of a product like this that supports such a wide range of devices and network topologies. I think this makes Roon an exceptional product overall.
Thank you for the detailed follow-up, and for circling back on the root cause. We’re glad to hear the playback issue is fixed, and that resetting the DAC2 back to USB 2.0 resolved it. It also sounds like there were a few other post-update issues on your side, so we’ll keep an eye on those as you continue testing. We appreciate the thoughtful feedback on support and on Roon overall. We’ll go ahead and close this one out, don’t hesitate to let us know if there are any further issues though. Enjoy the music!
