Audio zones lost after Roon update on MacOS (ref#T0R2N8)

What’s happening?

· Other

How can we help?

· None of the above

Other options

· Other

Describe the issue

I read the change log for 2.56 (Build 1582) and noticed that an issue where audio zones are lost during Roon’s update process on MacOS was resolved. I’m unfortunately still having the same issue, and have consistently for the year I’ve used my Mac as a Roon server. Following an update of Roon, the server comes back online but Roon remotes only display the Mac’s own output. I have to shutdown Roon server via the Menu Bar icon at the top of the display on the system running the Roon server, then relaunch the service.

Describe your network setup

Mac -> (very close to) TP-Link Omada EAP650 wireless AP -> TP-Link Omada managed Switch -> Firewalla Purple router -> ISP cable modem. Local wireless network sustains 700Mbps up/down where the Mac is located. Wireless APs are connected to the switch via Ethernet.

Network endpoints are Apple TV and Cambridge Audio AXN10 streamer, both connected wirelessly.

Blackhole is an audio loop back device driver installed on the Mac running Roon server.

Hello @soks

Thank you for the update.

The next step here is to gather more detailed diagnostics so our technical team can take a closer look. Before we enable diagnostic mode on your account, we’d like to make sure we capture the correct event.

Please reproduce the issue once more and note the exact time (including date and timezone) when it occurs. Then reply back here with that timestamp — this will help us correlate the correct entries in the logs.

In addition, please also send us a copy of your logs:

  1. Use the directions found here to locate your logs:
    https://kb.roonlabs.com/Logs
  2. Upload the logs to our secure file uploader:
    https://workdrive.zohoexternal.com/collection/8i5239cc05950ac07456889838d9319545a82/external

Once the logs are uploaded, just let us know here.
As soon as we have the timestamp + logs, we’ll move forward with the diagnostic review.

Thanks!

Sounds good! Happy to have logging turned on. It looks like updates go out roughly monthly, so is there a way to rollback the current update to create a reproducer sooner than the next official release?

Hi @soks,

This is not possible, unfortunately. I’d also test out using Roon without any virtual audio drivers and see if you run into the same issue.

Does this happen every time you reboot the machine?

We’ll be monitoring for your reply - thank you!

Hi @soks,

We see dropouts between RoonServer and local/upstream addresses throughout diagnostics logging associated with your account. These aren’t limited to device discovery traffic between RoonServer and endpoints/remotes.

Have you ensured that Roon’s processes are safelisted in the Firewalla router security settings? Please also ensure that multicast forwarding is enabled in any managed network components.

Where are your networked endpoints and remotes connected relative to RoonServer? Do they share an access point or are there hops in between?

Ooh, interesting. I don’t see anything specifically Roon-related getting blocked, but I also haven’t specifically whitelisted any behavior. I just did a quick observation while streaming and everything looked okay, but there may be random attempts getting blocked? I’d love to try and correlate the Roon and Firewalla logs to see if there’s something that needs to be allowed through.

In terms of placement, the machine running Roon and an Apple TV are definitely serviced by the same AP. There’s another streamer (AXN10) on another AP. But both APs are on the same VLAN and devices can communicate without any issues. I’ve tried to keep the individual VLANs as close to a standard network as possible, devices just can’t communicate across VLANs. Also, both APs are wired to the same switch.

In terms of reproducing when restarting the machine, I’ll try and see what happens! If I can read my logs, I can also try to correlate the failures you mentioned.