Never experienced this one before. This morning in starting up Roon radio station playing all seemed as it should. Roon accepted my request without any errors and thought it was “playing” via the Network Bridge but no music was coming from the speakers. Opened the dCS iPad app but received an ominous spinning wheel and was unable to venture past the initial screen. Used Fing app to verify that I could ping the dCS and see its typical services. Went back to find that Roon “playback” had stopped. Tried to restart the station but was not successful initially. Then about 5 seconds later music started playing. Returned to the dCS app and it initially balked but in a few seconds it too allowed me to see the playback screen.
Not clear what can be done at this point to identify what caused this to occur. Any ideas?
This indicates that the one of the software modules on the network card got into a funky state. It will usually self-recover, but that process happens quickly so if you’re not able to see the device for an extended period (minutes) then it’s best to power cycle it so that everything resets. Given the issues that you’ve been experiencing with Roon lately you have a higher likelihood of seeing these error conditions.
Appreciate your quick response and detailed explanation. I’ve learned to wait and let the software attempt to correct itself. My long time experience with TCP/IP has always suggested that waiting, given the fact that the protocol was developed to run across less than ideal networks – and a TCP/IP timeout value is usually specified in minutes. And, as you say, given the strange issues of Roon Core crashing randomly, I’m not shocked that it may well play a big part in the NB’s challenges. That this happened in the morning, when nothing has been playing for hours from Roon until I woke Roon up is even more likely that Roon is the culprit.
Do you think I should let Roon Support in on this latest “event”? Maybe they will see something in the Nucleus based Roon logs.
This is nothing to do with TCP/IP. This is the software on the card locking up. If it gets into this state it may recover, but in many cases it’s unstable until the next time it’s rebooted.
I’ve seen this scenario before (not your specific case, but similar cases where the endpoint gets vapor locked) and the core has very little visibility into what’s actually going on. All it can really see is that it has a stream open (or is trying to open one) and the endpoint is either receiving data or it’s not. We’re actively working on a bug that is similar to the one you describe.