I am having the same issue with ROCK and Ropieee after upgrading the Ropieee zone to 2.60 Bridge.
Right now it’s only impacting one zone (the single zone that I installed 2.60 Bridge on). I realise it’s possible that this is because I’m still running 2.58 Server, but I have no interest in losing all audio entirely so I’m hesitant to upgrade the server to 2.60.
Yes this the cause, they have kind of forgotten about Early Access users with this bridge update:
I don’t recall any cases of losing audio entirely with 2.60, except if people were running mixed installations of production and early access, which one simply shouldn’t do.
Of course you can simply wait until Roon fixes the bridge-with-EA mess
Thanks Suedkiez, for reference I’m not running EA, just the normal (old) stable. But due to many previous times that updates broke things, I have everything set to manual update and never upgrade more than one thing at a time (which is why I started with a less important zone).
The bridge is not normally the same version as the server (or at least hasn’t been since we left legacy) so I wasn’t expecting this issue just from updating one zone. If 2.6 now “must” be in sync between server/bridges then it would be good if they noted that in the release notes 
. For the moment I’ll stay on 2.58 and wait to see what is announced next week.
Thanks,
James
Right, I got confused 
Yeah there was this potential security issue now that forced them to change the code signing, so this time there was an update to bridge as well, after it had not been updated for a long time.
In their defense, the release notes do state that the update applies to bridge, too:
https://community.roonlabs.com/t/roon-2-60-and-roonbridge-2-60-are-live/315346/3
To the best of my knowledge, the code signing is the only change between 2.58 and 2.60, and I don’t recall any complaints that 2.60 made anything worse (or better) than 2.58, provided that one didn’t have an unholy mix of EA and Production.
(Plus the issue were the new bridge doesn’t work with EA because they didn’t provide an accompanying EA update)
But not that they need to both be done for anything to work. No previous update has broken communication between server and bridge in this way and needing to do both at the same time is not called out. The remotes update to 2.6 fine and still talk to 2.58 without issue (since the remotes are controlled in part by Apple/Android anyway).
And I realise you’re just a user trying to help, am just frustrated with their poor communications.
In a networked system like Roon, I think it goes without saying that everything should be updated for which there is an update.
Though maybe yeah they might have added this explicitly to remove all doubt.
Because there were no bridge updates in ages.
But there were other updates in the past that required updates to remotes as well for it to work.
Hi @David_Hampson,
This behavior—where audio devices appear but get stuck on “Enabling…” or disappear entirely after an update—is a hallmark of the stricter network security introduced in recent macOS versions (Sequoia and the newer Tahoe).
As @Suedkiez correctly noted, macOS often silently revokes or glitches the “Local Network” permission for Roon after an application update, preventing the core from properly handshaking with audio outputs. As you see, the same with the Chrome browser.
Please try this specific toggle to reset the permission:
Open System Settings on your Mac.
Go to Privacy & Security > Local Network.
Find Roon and Chrome in the list.
Toggle it OFF, wait a few seconds, and then Toggle it ON again.
Restart Roon.
Does this clear the “Enabling…” hang for you?
Hi @James_Fitzell,
It looks like your issue is related to Roon Bridge connectivity, which is quite different from the macOS Local Audio / Permission issues discussed in this thread.
To ensure you get the right help (and to keep this thread focused on David’s Mac issue), could you please post your details in a new topic in the Support category?
This will allow us to troubleshoot your specific network/bridge setup without confusion. Thanks!
@vadim - @James_Fitzell is running Roon Server version 2.58 - which is what is causing the incompatibility with RoonBridge 2.60.
He needs to upgrade all his devices (including the Roon Server) to version 2.60 so that they will all talk to each other with the new version of RAAT that has been introduced in version 2.60
Hi @Vadim. With the help of @Geoff_Coupe and @Suedkiez I was able to fix my problem by updating my Mac to early access to match my NUC/ROCK. My audio devices are working properly with Roon once again. Thanks for reaching out.
I am experiencing this same problem. Not using EA. My endpoints and Roon Bridges updated to 2.6 but ROCK on my NUC fails with ‘There was an error checking for an update’ immediately after it tried to download the Server update on my NUC Rock. I tried power cycling my NUC but no change.
FYI - I did log a separate Support ticket this morning before I saw this post.
Just suggested something on your Support thread…
Just replied there. Nope, doing an OS reinstall did not work.
This has been happening for years now and it keeps happening. I am so annoyed, I won’t be renewing my subscription at the end of the year.
On Mac, in particular, during updates, the Core loses all remotes, or updates crash remotes, or updates crash the core, or the Core iMac needs to be rebooted to re-discover it has remotes on the network.
And on, and on, and on…
For those experiencing similar problems, I can confirm that server 2.60 talks to bridge 2.58 fine. The issue only occurs with server 2.58 (or EA) talking to bridge 2.60. So if you want to stagger the deployment you need to start with the server first (it’d be good if that was covered in the release notes).
This is super annoying, unfortunately there is not an alternative in terms of software. Audirvana is even worse in terms of support and bugs.
Your only Support ticket was three years ago and ended with you saying it was fixed and not answering further. Maybe you can get to the bottom of this if you open a new one and let support figure it out.
The issue here in this thread was not a Roon issue as such and could be traced to a version mismatch.
I found the fix for my being unable to access ROCK OS on my Mac Studio. Chrome had periodically been asking for access to my local network and I kept refusing it. After researching why it was asking for this and not finding anything negative about the ask, I allowed it when it next occurred and that solved my access problem.
Ok I see, thanks. I think the reason they might be requiring the permission in general for apps is for protecting against ransomware spreading on the local network.
But since people need local access for browsers all the time to configure routers, NAS, and lots of things, it should really provide better explanations and management options.
Well, I just tried again and it failed to load. Maybe someone else will come forward with a fix.
