So, basically they realized they forgot to merge the fix into the EA branch, they are doing this now, and will release soon?
Isn’t it supposed to work the opposite way?
I think that’s a fair comment. It’s generally pretty poor form to brick your customers’ endpoints without asking 
hopefully there will be a change in process following this to avoid a repeat.
Gosh, if only there was a framework for IT service management that Roon could use to reign in their constant release cock ups.
Even a spreadsheet with level 100 questions. “Will this release cause a failure due to level disparity between any component?”
i think we can conclude from roon’s lack of response that this issue isn’t important to them…
I did switch back to “Production 2.6” and being fun with music. 
Well, I’m not sure that “we’ve got the fix but you can’t have it” is the comms strategy I would have chosen around this 
Yeah, I may have to do the same 
Yeah, I may have to do the same
Conspiracy theory: the EA programme is dead and this is the way they brought it about so everyone has to move to Production.
Of course this is not true; most conspiracies are actually incompetence because its more likely people make poor decisions than they all coordinate perfectly to deliver the outcome the conspiracy theorists believe.
Joking aside, the EA documentation acknowledges that,
This will be the final testing cycle of our products and its purpose is to expose changes to as many different configurations and use cases as possible. As such it’s critical that we maintain a healthy number of participants in the Early Access program.
So chasing specific populations out (Bridge users in this case) might not be the best strategy.
This post was previously flagged for moderation. I simply asked when a release will be made, not sure what I did that was wrong. The post unedited is still below …
@vadim i assume you meant a fix release was targeted for Friday 20th February. As it is now Tuesday 24th can you confirm the release date?
I’m wondering if the release of this known fix may have got bogged down in also trying to address the other blocking issue for a swathe of customers - Roon Ready Playback Failing to Initialize After Update to 2.58, Restart Potential Workaround [Roon Investigating] - #119 by Joe_Spagnola ?
If so, it would really help those of us on EA if they can be separated. Whilst it sounds simple enough to just migrate the server to production, in practice it’s a real pain because of the number of separate Android devices on which Roon would also need to be uninstalled, reinstalled and reconfigured to move off the ‘beta’ branch. It’s bad enough losing all one’s ARC downloads every time something goes wrong in a release!
Hey everyone - apologies for the disruption here, and especially for the fact that we shipped an out-of-cycle Production update for Roon Bridge (2.60) without a matching Early Access server build alongside it. You’re seeing a real compatibility mismatch: EA RoonServer 2.59 can’t fully communicate with Roon Bridge 2.60, which is why endpoints disappear or get stuck while enabling.
The reason this happened is that the current EA code has diverged quite a bit from the previous release, and back-porting the fixes we shipped into Production into the EA branch turned out to be more challenging than it should have been. That merge work delayed the EA update, and that’s on us.
We’re very close to having this resolved now. We expect to ship updated EA Roon/RoonServer builds today or tomorrow, and those builds will restore the ability for EA servers to communicate with the newly-released Roon Bridge 2.60 devices. We’ll post again here as soon as the EA build is live.
7 Likes
Thank you @vova its really good to hear that we are close to having this issue resolved.
“Back porting” typically describes the process of taking something implemented in a future or current build and porting it back to an earlier release. The fact that you started with Prod and then struggled to get the changes into EA suggests that you were under very high pressure to get something out very fast.
We know this was a security-driven patch. That’s all we know. We also know, by implication, that the normal approach of EA first then back port to production wasn’t used.
Was this a compromise? Was it theoretical or were attacks observed? If our home infrastructures were possibly compromised or data was exfiltrated, you are very possibly legally obligated to report to regulators and possibly legally obligated to report to users.
Do you intend to provide more transparency around what happened?
Well, that explains why I’ve not had problems, The system I always use is only set up for NAA.
Is there a wider issue here? my iphone/ipad are continually in a state of enabling (mercifully resolved by disabling & re-enabling the device) and this has been happening for years (with & before Roon Server), there also doesn’t appear to be a resolution in sight.
My personal view is that roon has more bugs than a rose garden and there appears to be little or no incentive to actually resolve them…
As Martin Luther King said….”i have a dream”……
Is it a case of “all bugs and no Nugs”?
Cloudflare issues - other service providers got round this
Forum update or DDOS attack 
EA/Roon Bridge 2.6 fiasco - 12 days to get a formal response to say it’s Roon’s fault……yeah, we known.
Not axe grinding but Roon’s response in all three is below par from what other services offer.
3 fairly substantial issues within a short period of time. Related?
Cloudflare issues seem to be because they’re updating/upgrading within their data centres. Roon should have prepared for this. If Roon are a customer of Cloudflare then they should have been made aware of this scheduled work. I’m getting daily emails from my employers IT providers about scheduled maintenance. Roon needs to invest in a fallback service for such occasions to maintain continuity of service.
The forum update issue, DDOS attack or whatever, added to the security update of Roon Server/Roon Bridge does lead to questions being asked by users.
The 2.6 update for security reasons, with little to no real explanation leads minds to wander.
As mentioned I think a little more transparency is required.
These are the release notes from EA 2.59 build 1625…
- Added scheduled Background Work, letting you control when Roon runs library maintenance tasks
- Resolved cases where Roon would stop updating now playing info for certain Live Radio Stations
- Folders that map to a single album now show that album’s cover art in the Folder browser
- Fixed an issue where the back-swipe gesture wasn’t working in the Android Roon client
- Fixed case when Speaker Setup in MUSE shows channels 7/8 instead of 5/6 for 5.1 zones
- Various fixes and improvements
There should be no reason that the dev team couldn’t go back to build 1625 and create a branch to release something like a “1625a” with the security fix. The new EA build did not have to reflect all of the other development newness since 1625. I certainly hope that Roon’s SCM system is capable of going back to these earlier versions to release branches when needed.
@vova, is EA release 2.61 (build 1632) solving this issue with Roon Bridge 2.60? The release notes are not quite clear on that.
As the man said:
Rest assured, the updated Roon will still work seamlessly with the production version of RoonBridge
And it does…