I have tried various times to log into the Nucleus, with no success. I have closed the RoonServer on my PC and I have renamed the RoonServer folder to RoonServer_old. I keep on dropping back to the Roon remote login screen. There is no new RoonServer folder created in my app files, so I cannot provide you with the logs from trying to login on the Nucleus.
After these tests, I have started the RoonServer again on my PC and this time I had no problems logging in with the pop-up windows working without a problem.
Thanks for the reply! From another fresh Nucleus diagnoistc report, we can see why login “pops back to the login screen”: the browser auth handshake itself succeeds, but when the Nucleus tries to finalize by calling back to accounts5, that call lands in the timeout bucket and the session never completes.
It’s also why Qobuz, Live Radio, and artwork all fail while local NAS/internal-drive playback works perfectly, only the outbound internet path from the Nucleus is affected. And it’s why Ben couldn’t enable diagnostics mode remotely.
Why the PC server “works”: when the PC hosts the server, the outbound traffic takes a different path/NIC through the network, which is stable. The Nucleus’s path is not.
The fault sits in the path from the Nucleus out to the WAN. Given the symptoms (connections that open then stall for 100s, ~50% loss, only the Nucleus affected), the most likely culprits, roughly in order:
The Deco mesh / its security feature. Your own Deco logs flagged the Nucleus for "Port Scan" and were blocking it. Deco's anti-IoT/IPS features intermittently throttling or dropping the Nucleus's outbound sessions fits the pattern exactly. Worth disabling Deco's "IoT protection" / "QoS" / any HomeShield/threat-protection feature for the Nucleus, or giving it a static IP excluded from those rules.
MTU / packet fragmentation on the Nucleus's path, classic cause of "connects then hangs" on long-lived TLS sessions while short ones succeed.
A duplicate-IP or DHCP-lease conflict for the Nucleus on the mesh.
Please try these in order and let me know where it breaks:
In the Deco app, disable any threat-protection / IPS / “HomeShield” / QoS feature for the Nucleus (or whitelist it). This is my top suspect.
Give the Nucleus a reserved/static IP in the Deco app so it’s consistently excluded from those rules and to rule out an IP conflict.
Connect the Nucleus by ethernet directly to the main Ziggo router (bypassing the mesh entirely), then reboot the Nucleus and try logging in again.
If step 1 or 3 fixes it, that confirms the mesh/security layer was the cause. Let me know how it goes!
I have very limited access to settings on the router part of the Deco mesh network, so after consulting my local computer shop, I installed a separate TP Link router before the Deco mesh network and switched the Deco to access point.
After some resetting and such, I have logged into the Nucleus and I can access Qobuz and play Live Radio. Looks like that issue is finally solved.
Only issue left now is that I can only find 1 of the 3 streamers in the network.
So it looks like I needed to go for option 4 (get a new router installed).
Are you still experiencing interruptions with Live Radio and Qobuz in the new network setup?
Please let us know, and we’ll investigate logs accordingly. Keep in mind that Qobuz is in the midst of resolving an issue with their upstream infrastructure that can cause some tracks to skip within Roon.