Playback instability when changing sample rates [dCS Network Bridge]

Hello @stevebythebay,

Thanks for letting me know. Our QA team is looking further into this so you don’t need to do any more testing. We are only seeing this behavior on a handful of installs so QA is trying to identify what’s triggering this issue. The reason why I wanted you to rest with no local content is that it would have been an extremely helpful data point in our investigation to verify that if the issue was with just local content or streaming sources as well, but I have made the note that it was affecting you when using Roon’s Internet Radio function in your case notes. We are still in the process of performing some additional testing and we will be in touch again after completing mentioned testing.


One thing that might be a consideration: the use of DSP. Over the past months I had been testing its use with my somewhat undernouriched Nucleus. I’d enabled Max PCM power of 2 for all my zones. Though only using one zone at a time, I had found that its use slightly degraded the sound in my system. That is, I was not getting the dynamics I’d been used to and there was a slight degree of “noise” or such in the system. Not the utter black background I’d come to expect.

I’ve since disabled DSP in the Nucleus. I’d already turned off volume leveling, which had its own sonic issues. Since then the system sounds quite a bit better, and I get the enablement of HDCD from my Berkeley DAC.

Will let you know if I experience the previous Roon glitches now that I’ve retuned the system to its basics.

Hello stevebythebay,

Thanks for sharing the update with us, we too are curious if DSP would have any noticeable impact here. Would you mind letting us know your processing speed under Signal Path with the DSP functions turned off/on?

Also, If you still notice the Nucleus crashing, can you please let us know what local time in your country that occurs at (ex.7:30PM)? Although QA is still conducting the investigation it wouldn’t hurt to have more times to see if there’s a commonality between when playback randomly stops.

I appreciate you reaching out to us with your feedback, please do let us know if you make any other discoveries on this issue.


When I did have DSP enabled the processing speed typically showed 16-20 so I don’t think the processor is being unduly strained. However, it’s quite obvious that using it does not bring benefits, only sonic degradation to the overall sound quality. Seems the dCS Network Bridge along with the Berkeley Ref. 2 MQA DAC do a far better job. I cannot see the processing speed when the DSP function is disabled under the Signal Path view. The two previous times the failure occurred it was during the morning – California time. Likely about 10 AM give or take an hour.

Hello @stevebythebay,

Thanks for providing the additional information, I have included it with your case over at QA. We will be in touch if we need anything else but I think we have what we need at the moment, the investigation by QA is still under way to narrow down what exactly is going on here. I will be sure to update you with their discoveries after they complete a report but we do not have an exact timeline of when that will occur.


FYI. Happened again today at about 11:55 AM PDST. Just suddenly stopped playing Allan Brothers Band. Initially could not connect to the web page. Eventually, within a few minutes, the iPad app saw the Nucleus and showed exactly where it stopped I could now “resume” where it left off.

Let me know if you want any info from the Nucleus. I think I recall how to find the folder/files/logs.

Today @ 12:54 PM PDST playing Clark Terry’s album “Portraits” cut called “Little Jazz” the song stopped about a minute in and then started up again about 10 seconds or so later. I stopped the song and restarted and it played straight through. Hope you might figure out why that happened.

Further: at about 1:05 PM Nucleus stopped playing. Via Fing could ping and see services but could not get web page at IP address to appear. A few minutes later Roon recoverd sufficiently for me to get to the web page. However, the IOS app could not connect. Then a few minutes later the app could connect. It showed that Roon had “stopped” 2 seconds into “Jive at Five” of the same album. I could hit the play button and it played from there.

Hope this helps.

Additionalally, the web page reflects that the Roon server restarted itself at about 1:08-1:09 PM PDST.

First sign of trouble I think (from the RoonServer_Log.02.txt):

07/14 19:54:12 Trace: [dbperf] flush 0 bytes, 0 ops in 18 ms (cumulative 345612144 bytes, 165750 ops in 129813 ms)
07/14 19:54:12 Trace: [dCS] [Lossless, 24/96 AIFF => 24/96] [100% buf] [PLAYING @ 1:20/5:47] Little Jazz - Clark Terry / Buster Harding / Roy Eldridge
07/14 19:54:12 Trace: [zone dCS] Previous
07/14 19:54:12 Trace: [dCS] [Lossless, 24/96 AIFF => 24/96] [100% buf] [LOADING @ 0:00] Little Jazz - Clark Terry / Buster Harding / Roy Eldridge
07/14 19:54:12 Info: [library] recorded play for profile 559c6cca-3660-4204-b574-d9d4fe08b685: mediaid=50:1:1b054686-dcb6-450a-8d68-897b26cdd3e4 metadataid=123:0:MT0033484909 contentid= libraryid=50:1:1b054686-dcb6-450a-8d68-897b26cdd3e4
07/14 19:54:12 Trace: [library] finished with 33 dirty tracks 3 dirty albums 41 dirty performers 33 dirty works 33 dirty performances 0 clumping tracks, 0 clumping auxfiles 0 compute tracks, 0 deleted tracks, 0 tracks to (re)load, 0 tracks to retain, 0 auxfiles to (re)load, 0 auxfiles to retain, and 111 changed objects
07/14 19:54:12 Debug: [library/index] updating search indices: 8 ops 0 adds, 0 removes
07/14 19:54:12 Trace: [dbperf] flush 0 bytes, 0 ops in 6 ms (cumulative 345612144 bytes, 165750 ops in 129819 ms)
07/14 19:54:13 Trace: [library] endmutation in 224ms
07/14 19:54:13 Info: [dCS] [zoneplayer] Playing: /roon/sys/storage/smbmounts/RoonStorage_ebbfbe74ddbde3522df3c827c372a1773cba2f20/Music/Clark Terry/1988 - Portraits (HDTracks 2004 24 96) FLAC/5-Little Jazz.aif
07/14 19:54:13 Info: [audio/env] [zoneplayer -> stream] All streams were disposed
07/14 19:54:13 Info: [audio/env] [zoneplayer -> stream -> endpoint] All streams were disposed
07/14 19:54:13 Trace: [dCS] [zoneplayer/raat] Endpoint dCS Network Bridge State Changed: Playing => Prepared

Had seeming success cueing the track which began playing when the “crash” occurred:
07/14 20:00:02 Info: [dCS] [zoneplayer] Queueing: /roon/sys/storage/smbmounts/RoonStorage_ebbfbe74ddbde3522df3c827c372a1773cba2f20/Music/Clark Terry/1988 - Portraits (HDTracks 2004 24 96) FLAC/7-Jive at Five.aif
07/14 20:00:02 Info: [dCS] [zoneplayer] Open Result (Playing):Result[Status=Success]
07/14 20:00:02 Info: [dCS] [zoneplayer] Starting playback

But tail of the file shows what seems like normal activity but obviously something happened to cause the restart of the server.

Looks like the end of this log corresponds to time just prior to restart of server.

Wish I knew what I’m looking at (with no source code to guide me). Need a mouse trap on this?

Please let me know if there are any files you need to review which you cannot access.

Hello @stevebythebay,

Thanks for letting me know about the new issue with the stopping and starting and I apologize about the slow reply here. I have enabled diagnostics mode on your account but no reports have seem to have reached our servers yet regarding your nucleus.

Can I please ask you to manually send us the logs from your nucleus? The instructions to do so were to navigate from another computer to your Nucleus directory by IP address, compress the files into one .zip file package and then upload it to our servers.

Please let me know when you have done so and I will submit those files for analysis.


I’ve zipped the log directory and uploaded as specified.

Likely that the specific instance I reported is in some other log as it appears they get created over time, and the issue cropped up on the 15th, as I indicated in my prior updates. Log names seem to change over time.

Hello @stevebythebay,

I can confirm that we have received the submitted logs and I will send them to the QA team for analysis. The logs automatically date back to a few weeks so rest assured, the information from the 15th will be visible. I will update you once analysis is completed.


Thanks. Really baffling what’s been happening. FYI. I went into both the Cisco switch and the QNAP NAS logs to see if there were any visible errors showing. Nothing appears to indicate that Ethernet has had any issues with dropped/resent frames. And there is unlikely any constraints on network performance that would suggest any problems. I did see mention of the dCS Network Bridge in the logs, but nothing that seemed to suggest that it was at fault, though in the past there have been numerous issues with it that required powering off/on to get it to cooperate with Roon, though these were typically when the bitrate of the source changed.

Hello @stevebythebay,

Thanks for the additional information, I have added that to your case. QA is aware of the issue you are facing and are reviewing the diagnostic info. I noticed that you have commented on the original thread, would you like me to add our conversation history there to open it up to the rest of the support staff?

I don’t personally have an issue with this, just let me know and I can move the conversation over in case you want more eyes on what could be going on here.


Fine with me. Certainly valuable to have more eyes on this. Hope you’re able to find the source of the problem, and more importantly, a solution.

Roon core crashed again today about 1:45 PM PDST. Let me know if you want latest logs, once again.

Hello @stevebythebay,

Thanks for letting us know, strangely enough when the Nucleus rebooted just now, the new diagnostic information was received by our servers and I have gone ahead and forwarded that info to the QA team.

They are still actively looking into this issue but have asked if you would reconsider running the original proposed test in tandem while the investigation takes place. The test I am referring to is this one:

If you would like to run this test and need a TIDAL account just let me know and we can provide one.

Another test we can run here would be to verify if the NAS is causing any issues. To perform this test please:

  • Load a USB stick with music of varying bit-rates and attach it directly to the Nucleus.
  • “Disable” (but do not remove) the NAS as a watched folder in Roon and set the USB stick as a Watched folder.
  • Play music for a while only from the USB stick and let me know if you run into the same issue.

These two tests will help us narrow down where the issue lies. Please let me know if you decide to run either of them and your findings when possible.


I already indicated that I experienced a failure in the past when only playing an internet radio station (KDFC) for many hours. See the thread Nucleus Core Death Spiral…

So, doing this test would be redundant, at least with respect to any Tidal related failure, unless a very different code path is involved.

And I personally dislike Tidal as a source🤬. I’d certainly expect that the focus is on my existing setup. My approach to problem solving is to keep it simple.

By the way, the only non-standard setup option I’m using for the dCS zone within Roon is a resync delay of 1000 ms.

Also, I’m still getting issues between the Nucleus and dCS Network Bridge when bitrates change. I’m beginning to wonder if I’ve got a hardware edge case. The Nucleus I purchased directly from Roon via Danny was not part of “full production” as I understand it, though I doubt it differs materially from later units. And the only physical connections to the hardware are the single Ethernet cable and external Roon supplied power supply.

One last thing to add, I’ve never experienced any glitch with any other zones, using microRendu and Audio Alchemy DMP-1 Roon Ready devices. Only difference compared to dCS is that these are WiFi accessed (Nucleus wired Ethernet to Cisco wired Ethernet to Eero mesh WiFi Access Point). And all default zone device settings).