Since the firmware update I’ve experienced this failure a couple of times. Guess whatever was fixed, it didn’t seem to work as well as I’d hoped.
Is there some means to capture what is happening or otherwise provide support with particulars so they can provide a fix?
My most recent experience: playing “Duke Ellington Presents…” 96kHz/24bit to completion followed by Teddy Wilson on “Masters of Jazz, Vol. 11” a 88.2kHz/24bit album. Roon presented the error right after trying to play the latter.
The chain is Nucleus (fed by NAS) wired to Cisco switch wired to dCS Network Bridge to Berkeley DAC.
I haven’t seen this issue on the bridge in any of the recent (or not-so-recent) development builds and one of my torture tests is a mixed-rate queue on repeat for days.
Two things come to mind.
First, what is your resync delay set to in Roon?
Second, I recall that you use a Cisco SG-200 managed switch and that back when you used micro rendu you had some issues which resulted in flow-control getting set on one of the switch ports. Check your switch configuration and make sure that flow control is disabled for all ports. Don’t forget to save the switch configuration (flashing indicator at the top of the browser window).
Have not changed the flow control settings. These, by default are disabled on the Cisco. If flow control is not enabled it caused problems with playback of high bitrates on the Berkeley. Once I enabled flow control I’ve never had an issue.
As for Resync delay, I chose to move from 4000 ms to 0 as I’d hoped the firmware update might fix the issue of Berkeley syncing with Roon (symptom was cutting off the first few seconds of first song of an album when switching bitrates). And I’d not had the symptom since the update.
I will return to adding the delay, though I’d not thought this was at the core of the dCS NB - Roon failure.
The network has zero influence on your DAC and vice versa. You were having problems with high bitrate playback to your DAC which was being fed via a micro rendu. You’re using a totally different device now.
This was an issue with the 100Mbit interface on your micro rendu. It shouldn’t be an issue with the bridge. For your reference I ran several bridges on a larger network using SG-200 switches and never had an issue. Also, if memory serves the setting was enabled on the port to your mac mini (which has now been replaced by a Nucleus+). So in other words, EVERYTHING has changed since then so it’s best to go back to the defaults and start over.
Most DACs require some sort of delay since most DACs fed via AES don’t switch rates instantaneously. This is especially important on the Bridge as it has no way of knowing when the DAC is ready.
A short delay is very useful in situations where sample rate switches are unstable. 4000ms is a lot and I would set it shorter (like 1000ms) unless you start missing the first part of the track because the DAC isn’t locked yet.
I would highly recommend disabling flow control on all switch ports and making sure that IGMP snooping is disabled. Save the config in the switch and reboot everything.
Based on your recent post history you have a few different issues that are pointing at your network.
Your memory is better than mine. You’re right about the combination of hardware at the time I enabled flow control. I’ve gone ahead and disabled it on the Cisco switch used for the audio system with Nucleus/dCS NB. Also, have reduced the resync delay to 1000ms. Will reboot all as you suggest.
Still getting frequent errors of Roon failing with dCS Network Bridge after bitrates changes. Seems more likely when moving from higher bitrates like 192k to lower ones like 88k or 44k. It’s the one about Transport: failed to select Roon as the current source, I believe. Just for info, I’ve disabled all DSP and volume leveling, using 1000ms delay and fixed volume.
Steve, given the history of your installation and some of the strange issues that you’ve been seeing I’m still inclined to point the finger at your network. I routinely test the Network Bridge using Roon with a mixed queue of everything from 16/44 to DSD128 (and everything in between) and have not experienced the extent of issues that you are. That’s not to say that I haven’t encountered any problems ever, but I’m not seeing anything near the consistency that you’re seeing.
I’m going to move this section of the thread into the Support category so that @support can grab some logs from your core and possibly shed more light on this.
Sorry ‘bout this. Already have been conversing with support about this and other failures, literal, of Roon. Thought I’d simply keep consistent due to the subject of this thread.
I can see that diagnostics have already been enabled on your account. I’m going to request a new set of logs and have the tech team look into this sample rate change issue you are seeing.
Can you review my most recent experience of Nucleus with Noris? I’ve been communicating via what appears to be a private Roon message. A QA case was started in mid-June on this.
I have started a case for you with QA but they kindly inquire as to some more information regarding the
Nucleus Crashing:
Can you please answer the following questions:
Do you have any airplay zones on the network ? Please mention even those which are not currently playing or are on the network but aren’t enabled in Roon.
Do you use iTunes anywhere in your current setup?
They would also kindly ask you to perform one more test with the goal of getting rid of as many external variables as possible. Please do the following:
Important: Create a backup of your current Roon DB first from your Windows Computer using this link as a guide. Do this step before performing any of the below steps
Move current DB aside
To do this step, please open Finder, click Go, then Connect To Server. Then type smb://IP_ADDRESS_OF_NUCLEUS_HERE/ and connect as a Guest.
You can find the IP address of the Nucleus in Roon Remote in Settings -> Setup -> Configure Roon OS Devices -> Configure and it should list the IP address there. More information on this step can be found here
The folder structure should look something like this (except you would see it as Mac OSX folders instead of Windows):
Then rename the current “RoonServer” folder to “RoonServer_Old”
Restart the Roon Server from the WebUI (Link to UI: Settings -> Setup -> Configure Roon OS Devices -> Configure -> Press the IP address for the Nucleus and it will open a web page). This step will generate a new RoonServer Folder (and database). The page should look something like this:
Make sure there are no watched folders in Roon (not even DMF, if it’s there - disable it)
Disconnect from the network all network zones you were using except the dCS device
Add only TIDAL (if you don’t have TIDAL let me know and we can provide you a trial license)
Try to use Roon in this setup for a few days
Let us know how it’s working and if something is wrong indicate what time the Nucleus failing
I realize that this may be an inconvenient test, but it will greatly help in narrowing down where things are going wrong. Please let me know if you have any questions about steps listed here and thanks in advance for working with us here.
Also, when you mean “watched folders” what precisely am I looking at in Settings? Right now the only thing I “watch” is the single Music folder on my QNAP NAS where all my music lives.
As for Tidal, I don’t have a license (had one for less than a month and didn’t care for it at all).
Yes. Had to turn off Roon. Still not clear what folders not to “watch”. Does that mean that you’re asking that I simply disable all library sources other than Tidal (which I don’t have a license to use)?
Hey…if you expect me to actually use Tidal, and not my own library, and just await a failure that happens once every month or so, I’m sorry but that’s not my idea of troubleshooting.
If your logs can’t show what’s going on, or you don’t have some additional code I can temporarily implement to help catch what’s happening, I’d rather let someone else be a guinea pig for solving this particular problem.
I’ve had similar requests from Apple engineering when they were at a loss in identifying problems on my systems, even when I could reproduce them at will!
I’m happy to use code to trap and trace, but not willing to give up my music to live with Tidal.
Note that the second time the problem occurred that I did nothing to the Nucleus. Did not reboot nor restart Roon. Simply waited until it reappeared as accessible on my iPad. If the logs fail to show anything, and you’ve no additional steps like adding debug code, beyond abandoning my library and just listening to Internet radio or Tidal, I’ll simply have to wait for others to get tripped up as I did. If the source of the problem is my QNAP NAS or Roon code (like a memory leak or such) it may never come to light.
I apologize if I was not clear enough with our intentions for the test. We wanted to ask you to run only off of TIDAL for a few days to narrow down if there is an issue with local content or all content in general. Rest assured this would only be for a few days to a week and not “awaiting a failure once every month or so”. With that said, we have generated a TIDAL Hi-Fi trail license for you and you can navigate to https://tidal.com/roon, click “Do you have a voucher?” and input this code: REDACTED. Please be aware that you need to use another email address that is not associated with the previous trial you used for TIDAL.
My suggestion while you perform the TIDAL test here would be to disable all your watched folders (you can do this in Settings -> Storage -> Clicking the 3-dot drop-down menu next to each of your music folders and hitting ‘disable’). If you can run this setup for lets say 3 days, then we can confirm that music streamed over the network is stable.
After 3 days of usage with only TIDAL and verifying that it is working properly, another testing option would be to temporarily load a USB stick with some music and plug it directly into the Nucleus to see if content attached directly to the Nucleus causes this crash as well, as content plugged directly in would not have the network aspect tied to it and we can eliminate some possibilities that way. If you wish to perform this second test as well, all you would need is a USB stick connected directly to the Nucleus with some music and have that run for 2 days.
As you can hopefully see with these tests, we would be able to narrow down where the music playback is failing and eliminate some networking variables in just one week of testing this setup. As always, if music playback fails suddenly in any of these tests, please jot down the exact local time in your country (ex. 11:45AM) and let us know when it occurs. I appreciate your understanding here and our intention is to not waste your time, but to narrow down what exactly is causing the crash. If you have any other questions, please don’t hesitate to ask.
As I indicated in my first post on the topic the failure happened while listening to music via Roon’s Internet Radio function (that is listening to a local radio station via Roon). The second time was due to listening to my local music files. In both instances the Nucleus was connected via Ethernet to my Cisco managed switch and the other Ethernet connected devices include my QNAP NAS (music file location) and Eero mesh-based WiFi access point which connects to the primary Eero wired to an Arris/Motorola cable modem to Comcast. So, that would seemingly rule out the source and point to Ethernet generally, only if connecting via USB “solves” the problem. However, that still might take a month or two of playing, and still not actually confirm anything…without actually trapping the problem when it happened.
So, as I said, your approach won’t guarantee finding the source of the problem, and may not even narrow it down to any relevant answer or any answer at all.
Like I said: come up with something that’s not a burden on my enjoyment of Roon and I’ll be happy to consider it.
