After playing for days and several hours per day, I get a “too many failures. Stopping playback” msg on playlists I do use regularly. The issue occurs with the Audio Zone containing a DENAFRIPS ARCAS streamer. All other AUDIO Zones work perfectly.
DENAFRIPS was working properly from day one until around June, when the issue occurred for the first time.
Went with DENAFRIPS back and forth for 2…3 weeks - no hardware or firmware issues could be identified. Magically it started working again after reinstalling the firmware sev. times. Since then I had no problems for two..three-ish weeks. But now the same issue re-appeared.
The issue itself leads to “no music” at all until a “fix” happens. No healing type of solution on another day. Reboot doesn’t help at all. That was the reason I was suspecting a HW issue with the DENAFRIPS in the first place. Now with the focus moving towards the ROON setup it really can’t be a hardware issue, as there is only one AUDIO zone making trouble. All others work.
My network traffic is usually on a “constant level”. No big up- or downloads despite either music or tv streaming in my living room. When working I am using a different Audio Zone without any problems at my office. So data amount shouldn’t be an issue.
Notable:
The current issue occurred approx. 1hour after updating ROON’s software. I am not quite sure whether this was the case for the initial June incident. (see 2nd).
Actually the issue occurred for the first time shortly after I received the NUCLEUS ONE. Not sure whether this is a coincidence. Before the Nucleus ONE I used a ROON SERVER running on Synology. That setup had issues too (minor from today’s perspective) .The server had short hick-ups and stops during playback for a couple of times peach day (which is pain in the neck, when listening to Classic or Jazz ). So I expected that a dedicated hardware would be better and would provide me with a more stable environment.
How does this all work together…
Network Hardware:
Fritz!Box 7590AX connects two LAN cables only, one is connected to the “Nucleus One” directly . All other LAN devices (two Synologies & a Laptop ) are connected via a Netgear switch to the Fritzbox.
The DENAFRIPS ARCAS LAN-connects via a SILENT ANGEL Bonn8 Switch to a FRITZ Repeater 1200AX
The SILENT ANGEL supports a Receiver, a TV and a Bluray/CD player too. Those three are not switched on when listening to ROON music usually.
FritzBox and Fritz Repeater 1200AX are in WLAN Bridge mode.
All audio, electronic and network components are updated regularly to the latest firmware.
Did you try to connect your Arcas directly to your router? This is, just to make sure there isn’t a faulty connector on a switch somewhere.
Also, what happens when you ise a different protocol? Your Arcas also accepts Airplay streams. Do your problems also occur while using Airplay?
In order to investigate this issue we would like to exclude the influence of the switch and repeater, as they are likely to be a bottleneck here so we would like to ask you to test the direct connection of the Arcas to the router if that’s possible and let us know what the outcome will it give as @Arlen mentioned.
Also, could you please clarify which Device are you currently using as a Roon Server because at this exact moment we might not see any Nucleus One device used with your account ?
The ARCAS at this moment works again connected via the „ short cut route“ to the router, but it worked also via the „long chain“, and yes AirPlay works too.
I guess I have to wait until the next event occurs to test it directly connected.
This is weird as during the DENAFRIPS checks it didn‘t work at all for more than a full week - consistently - „long chain“ as well as „short cut route“.
I did test the short cut route at that time too.
Can you recommend special settings for „long chains“? It cannot be a data amount issue, because the same connection supports 4K streaming without any hiccups.
The other subject … the Nucleus ONE has been bought with email [redacted] and the ROON account runs with [redacted] Is it possible to consolidate the two separated „accounts“ somehow?
We’re waiting for the next time the issue occurs so that we can collect diagnostic data. Please make note of the exact timestamp and share it here when it happens.
Unlike video streaming, RAAT is a real-time audio protocol with little to no buffering. This means that network stability, latency, and error handling play a bigger role than raw bandwidth. The quality of the file being streamed can also have an impact.
In terms of best practices: everything should ideally be wired. If you’re not fully familiar with configuring managed switches, it’s best to avoid them, as misconfiguration can introduce issues. Beyond that, recommendations would depend on the details of your specific setup.
Everything should be wired. If you are not sure how to make the most of managed switches, it is best to not use them. That’s the best practice. Everything else should be reviewed based on your use case.
From a support perspective, the account separation doesn’t affect troubleshooting. I’ve tagged the @accounts team so they can follow up with you directly about consolidating.
We hope this message finds you well. We haven’t seen a response from you above concerning your original technical question, the dropouts with the Denafrips Zone.
The most immediately useful step would be to bypass the managed elements in the network pathway between the Nucleus and the Denafrips, connecting both directly to the router via ethernet.
The switch between the Zone and the Nucleus may be delivering packets out of order due to its packet scheduling and STP implementation. Let’s simplify the network setup and capture new Roon logs so we can pinpoint what’s happening.
I did follow your recommendation for the signal chain. Now the NUCLEUS ONE AND the DENAFRIPS ARCAS are LAN-connected to the router directly. No repeaters or WLAN segments anymore.
I did test the stability and the issue is present still. Streaming stops in minutes.
So I tested the concept again.
I was reactivating the ROON server running on my Synology. (The synology is also directly connected to the router).
Streaming of QUOBUZ content, but also MP3 Radio Stations worked without any interuption. ( I did keep other network traffic low during these tests intentionally).
I switched back to the NUCLEUS ONE. After 10mins straming stopped abruptly. I had unpower the components to get streaming running for another couple of minutes.
Switching between the server confirmed the issue pointing at the NUCLEUS ONE.
How shall we proceed?
Best regards,
HAns-PEter Trum
To help our technical team investigate the issue further, we’d like to enable diagnostics on your account. Before we do that, we need your help to gather the right information:
Please reproduce the issue one more time and note the exact time at which the error occurs.
After reproducing the issue, please collect a set of logs by following the directions found here.
Additionally, please take a screenshot of the Signal Path from the affected playback zone and include it with your response.
Once the logs are uploaded and we have the timestamp and Signal Path screenshot, we can review the diagnostics related to that time and provide further assistance.
Thank you for your help — this will allow our team to get the best insight into what’s happening.
Thanks for sharing that timestamp! We were able to observe the following error, which stopped playback:
Warn: [HPT-DENAFRIPS] [zoneplayer/raat] Failed to prepare DENAFRIPS in 15000ms. Giving up
Warn: [HPT-DENAFRIPS] [zoneplayer/raat] failed to setup any endpoints..giving up
Warn: [zone HPT-DENAFRIPS] Track Stopped Due to Error
The streaming from Qobuz itself looks fine: Track buffers were retrieved (FirstBlockRetrieved, AllBlocksDownloaded).
HTTP calls to Qobuz and Roon metadata servers all came back with 200/201 responses.
So the media stream is ready, but the playback chain falls over when Roon tries to hand it off to your endpoint. What’s stopping it is endpoint preparation/handshake failure between Roon and the DENAFRIPS over RAAT.
A few next things to test:
Make sure the DENAFRIPS DAC is on the latest USB firmware. Older firmwares are notorious for handshake delays/timeouts.
Make sure no other processes are grabbing the device before Roon can.
The Denafrips is on the latest firmware and is, as the NUCLEUS ONE, directly connected to the Router using CAT 8 cables.
I had provided your analysis to DENAFRIPS, but not heard back.
As I was taken with other stuff, I have to admit, that I didn‘t pay attention to this subject since mid Sept.
I will ping Denafrips on the matter today and see what their response will be.
Assume the hardware being connected with top cables on the shortest path.
This is not the issue.
The issue exist between the Nucleus ONE and Denafrips ARCAS.
As said the server running on Synology works reasaonably well, with short hickups. The Nucleus ONE/ARCAS config stops in minutes. I had forwarded your analysis to DENAFRIPS „ages“ ago. No feedback, nothing despite poking them sev times.
As I feel sitting between a rock and a hard place, I have cancelled my ROON subscription and move away from the Denafrips transport too. I will get a new transport in the next days, which will be able to use Qobuz Connect. That is not perfect, but at least I will be able to hear my streaming services soon again.
You may close this thread. Thx.
I’m sorry to hear this @Hans-Peter_TRUM, but certainly let me know if you’d like to pick this back up at any time - we’d be happy to set you up with a free trial to continue troubleshooting if Denafrips ever follows up.
). So I expected that a dedicated hardware would be better and would provide me with a more stable environment.
