· My recently purchased Titan with an upgraded 32GB of RAM has finally received all my music files of over 30,000 albums and my playlists. Now experiencing an intermittent problem, while playing music it will stop and ask me to select an audio zone which takes a few minutes to go back the DCS music option, which is an inconvenient disruption.
Tell us about your home network
· My router is a Cisco CBS1 10-8T-D hardwired to a pakedge SX-8P switch also have a few eero Pro 6E extenders throughout the house and an iPad Air 5th generation for my controller.
I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.
However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.
First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.
Thanks for logging that timestamp, it made this much easier to pin down. I’ve been through your diagnostics.
What we found: your Roon Server is briefly losing network reachability to your audio devices, 36 separate times in a single 23-hour window. Each time, it stops receiving data from the dCS Vivaldi and then can’t reach it again for a stretch.
This isn’t specific to the dCS. At the same instant the Vivaldi drops, your Roon Server also loses the SHIELD Android TV (all 36 times, within seconds) and the SMB shares on your DS923. Three unrelated devices vanishing together, repeatedly, points at the network path rather than any one device. Your internet connection stays up throughout, so this is local traffic being interrupted, not the server dropping off entirely.
Why you land back at the zone picker: the interruption itself is often only ten seconds or so, but losing a zone mid-playback tears it down, which is what sends you to the zone selection screen. Roon retries for about 45 seconds, then waits for the next discovery cycle, in the worst case we measured, six minutes. We’re looking at that recovery behavior on our side, but the interruptions themselves are happening below Roon.
What would help:
Which switch and port do the Roon Server, dCS, SHIELD, and DS923 each connect to?
Are the eero Pro 6E units in bridge mode, and is any of them wired back into the Cisco or Pakedge?
Is there more than one cable path between the Cisco and the Pakedge? A second link between two switches can cause exactly this pattern.
If it’s easier to hand the switch side to your installer, feel free to point them at this post.
Upstairs is where my modem (supplied by Spectrum) is hooked up to a coax cable from the wall. The modem is connected via Ethernet to an eero pro 6 which is connected via another Ethernet cable to the Cisco router (also upstairs). The Cisco router has two long Ethernet cables connected to two switches in the basement. One connected to the pakedge switch where the Roon Titan is connected to (port 8 of the pakedge switch) and the second Ethernet
cable is connected to a Nordost qnet 7 switch.
The qnet 7 switch has the following connected into it:
Port 7 - Nvidia Shield
Port 6 - Reiki switch which is connected to the DCS music upsampler / streamer via an Ethernet cable.
Port 5 - Open
Port 4 - Ethernet cable to a grounding device
Port 3 - Ethernet cable to my NAS ds923+
Port 2 - Open
Port 1 - Long Ethernet cable from upstairs router.
Should I have the Titan connected to the qnet 7 switch (port 2 or 5) instead of the pakedge switch?
Update from my last reply. My upstairs modem that is connected to an eero pro 6E via an Ethernet cable is my router that is connected via an Ethernet cable to the Cisco switch that are all upstairs. From the Cisco switch upstairs there are two long Ethernet cables going to my basement one connected to the pakedge switch and the other connected to a Nordost qnet 7 switch. Plus I have seven additional eero pro 6Es throughout the house that are WAP / mesh system that are all in the automatic mode. I hope this helps clarify my situation.
Here’s what stands out: every device that drops, the dCS, the SHIELD, the NAS, is on the qNet 7, and the Titan is by itself on the Package. So all 36 interruptions involved traffic crossing from the Pakedge, up a long cable to the Cisco, and back down another to the qNet. Nothing on the Titan’s own switch is affected.
So yes, to answer your question: please move the Titan to the qNet 7, port 2 or 5. That puts it on the same switch as everything it talks to and takes the Cisco and both long basement runs out of the audio path. If the dropouts stop, we’ve found the problem. If they continue, we’ve ruled out a big piece of the network. Either way it’s easy to undo. Note the date and time you move it, then post here with any new dropout time and I’ll compare diagnostics before and after.
Two things I’d still like to confirm:
Are any of the seven eeros connected by Ethernet, to the Cisco, the Pakedge, the qNet, or a wall jack anywhere? An eero that’s wired in while also meshing wirelessly can create a loop, and the CBS110 is an unmanaged switch, so nothing in your setup would break it. That produces exactly this pattern.
If your installer is around, the Pakedge is managed and has a web interface. Ask them to check link speed and error/flap counters on port 8 and the uplink. A long in-wall run negotiating at 100Mbps or flapping will show up there.
Thanks for your updated reply. None of the seven eeros are connected to the Cisco, pakedge, qnet 7 or a wall jack anywhere. I don’t know of anyone to check the link speed, etc of the pakedge.
I did a total reboot of my network and plugged the Ethernet cable from the Titan into the Nordost qnet 7 switch into port 2 and fired everything back up around 5:10pm eastern standard time and it caused my dcs and the shield to go off line. This happened originally and that’s why I plugged the Ethernet cable from the Titan into the pakedge switch which didn’t cause this to occur. Now I can’t connect to the Roon Server on the Titan or the NAS. Apparently it doesn’t like the qnet 7? Any other suggestions. Please Help!
Thanks, Bob Jahn
I did a partial reboot of my network and reconnected the Titan Ethernet cable to the Pakedge switch into port 2 and everything is working for now. This occurred around 7:10pm eastern standard time. Will monitor to see if the change audio zone occurs again.
What about if I try to eliminate one of the long run Ethernet cables from the Cisco switch upstairs to the Pakedge switch in the basement and connect the qnet 7 to the pakedge via an Ethernet cable and connect the Titan to the pakedge?
Back to the original set up and select your audio zone disruption occurred at 8:36pm eastern standard time. Please let me know your thoughts on eliminating one of Ethernet cables from the upstairs Cisco switch and connecting the qnet 7 and pakedge switch via Ethernet cable and connecting the Titan into the Pakedge switch. Or any other suggestions you may have.
Thanks, Bob Jahn
I might have resolved the issue. I eliminated one of the long Ethernet cables from the Cisco switch to the qnet 7 switch and connected the qnet 7 to the pakedge switch with an Ethernet cable and connected the Titan to the pakedge and did a partial reboot of my network and all appears stable since 6:45pm Sunday evening. Could you please run a diagnostic test as of 6:45pm Sunday to see if you can see any issues. Also, do you have any idea why by connecting the Titan to the qnet 7 switch it causes the shield and DCS to go offline?
Also is it OK to keep the “Background Audio Analysis” in library settings unscheduled turned off at all times?
Thanks for all your help!
Bob Jahn
The diagnostics from Sunday evening confirm the network drops have ceased. The dCS, Shield, and NAS are maintaining a continuous, uninterrupted connection to the Titan.
To answer your specific questions:
Why the QNET dropped devices: Audiophile switches like the QNET are heavily optimized for low electrical noise rather than high data throughput, often utilizing very small internal data buffers or intentionally limiting certain ports to 100Mbps. The QNET likely flooded the switch’s limited buffers, causing it to lock up and drop the dCS and Shield. By connecting the Titan to the Pakedge (a switch designed for heavy network routing), the Pakedge handles the heavy data lifting, allowing the QNET to easily process the isolated audio stream.
The new network topology: By daisy-chaining the Pakedge and QNET and eliminating one of the long runs to the Cisco switch, you simplified the physical network path. This likely eliminated a broadcast storm or a routing loop that the Cisco switch was struggling to process across two long parallel runs.
Background Audio Analysis: It is perfectly fine to leave Background Audio Analysis turned off permanently. Roon will simply analyze tracks on-demand right before they play. The Titan has more than enough processing power to handle this on-the-fly analysis without any impact on playback performance.
We will keep this thread open for a few more days. Let us know if the stability holds.
Roon can struggle with enterprise network setups because they tend to over-optimize traffic in a way RAAT often doesn’t expect.
High-performance managed switches will perform deep packet inspection and actively manage the traffic flow, often rerouting packets to speed up a particularly active connection between certain devices. Roon relies on sustained, long-lived TCP sessions during playback with RAAT. This architectural mismatch can create some pretty thorny network problems that are often best resolved by bypassing the managed switches and simplifying layer three and above.
If you ever want to work through the particulars of this network we’re more than happy to assist. Here are our general recommendations, in case you hadn’t seen them: