I'm receiving the "waiting on roon server" message sporadically. The entire roon system is on a wired network with level 3 managed switches, same subnet, same vlan. IGMP snooping and broadcasting within the network is permitted and working fine with higher bit rate 8k video streaming.
The error occurs when controlled via a roon app to different endpoints including an Universal Audio Apollox8 connected to Mac M4pro via TB3 and an RP4 connected via USB to a Topping D90III discrete.
Originally I had the roon server running on a Qnap NAS TVS-h674 (i5-12400, 64GB with db and music on pciex4 nvme SSDs). I originally noticed the problem streaming higher bit rate content to the D90III. The Qnap specs seemed reasonable, but I opted to relocate the roon server to the M4Pro (Sequoia 15.3). Things seemed fine for about a day, then the same problem occurs.
This is now using a different roon server software on a different platform and streaming to the Apollo x8 (on the same machine as the roon server) as an endpoint. I have seen the problem streaming off of different endpoints while streaming flac files from the NAS via a share to the Mac, streaming off of the NAS drives to a roon server on the NAS, streaming via tidal with the roon server on both the Mac and the NAS.
How can I identify what roon server is trying to do that the network does not allow and is confusing the works. Roon is incredible, but this is very perplexing. I was planning to get a lifetime subscription. Now I am hesitant.
Describe your network setup
All wired. Firewalla firewall. Ubiquiti Enterprise 48 PoE. Second network for core devices on 10GBE wholly unmanaged dumb switch. Separate subnet, no internet access. Only a few core devices including NAS, MacM4Pro and windows PC. No roon endpoints should be attempting to us this network, but I can't seem to find anything on the server or the endpoints to force the services to use a specific mac, subnet or defined NIC hardware. I hope I'm just overlooking it because sending a dog on a hunt without a sniff, when the network paths are known, is not the best approach.
Enterprise networks can cause problems with Roon due to its reliance on dynamic port assignment and uncompressed PCM. The most common culprit in a managed network environment is the routing optimization features in managed switches.
The most useful test would be the remove the next-gen firewall and L3 components in a sequential A/B test and then build these components back in. Diagnostic logging shows RoonServer receiving an unexpected broker ID from certain remotes mid-playback; while this doesn’t affect the audio stream or buffering, it will result in a temporary “Waiting for RoonServer…” screen while the client and broker resync.
Network-savvy users often request this feature, but Roon doesn’t currently have the capability to restrict itself to a single network pathway. RoonServer will use whichever network interface offers the best speed on startup.
Thanks for the insights. I’m going through the your steps and testing now.
Is it possible to determine the ip addresses of the nodes with the unexpected broker ID?
I notice that I may have left out a portion of the roon endpoints I had forgotten about. I brought in a backup database from my old Roon server from many years back. Included in it were some Chromecast Audio endpoints (yeah, the good ones with no video that looked like miniature records). Apparently they remained in the db, enabled and to my surprise still powered on in a closet downstairs. So, I do have some wifi devices on the network…or did when I experienced the messages.
The devices on my network are easy to find from an IP scan. I’m not seeing anything in Roon that tells me about an trouble causing endpoint not in the Audio tab.
What appears to have happened is devices running Roon Bridge 1.7 are hitting the Roon Server 2.x. Since the old Roon server had the same IP address, Roon Server 2.x is getting requests it does not know how to process. Since they are incompatible, these RoonBridge 1.7 devices never make it to the Audio devices list. Unfortunately, they appear to be throwing a wrench in the cogs.
I’m assuming these devices are the ones responsible for the log messages mentioned in the original support response.
I’m looking for the IP of any device in the Roon Server logs that provided an incorrect broker ID.
Can you please let us know the exact local time + date when you next receive this error? I wonder if logs will show anything, we can enable diagnostics and take a look after we recieve this timestamp.
Also, looking over your general logs, it looks like your Roon Server is assigned 3 IP addresses at the moment. Are you able to limit the server to just use one IP address temporarily, to see if the issue subside?
It looks like I’ve managed to sort out all of my home network problems.
Roon is now running stable with no interruptions. I am able to stream the highest bit rates to multiple endpoints without any problems. This includes files from my server as well as via 3rd party network streaming services.
