The requirement to log in again and to unauthorize, as well as the jellyfish staying there unusually long affected many (all?) testers of this update. See the beginning of this thread for examples. You might additionally get an error with the metadata improver, which will need one more core reboot.
Inconvenient but not to worry, and being worked on.
It seems to be sync’ing Qobuz now, and taking its own sweet time about it! We’ll get there eventually…
anyone try uefi?
strange, ill look into this, but i haven’t see this… its strange, since we blow away the disk before we start…
the new builds no longer supports the branches folder. instead, check /Reinstall – there is a readme in there that explains how to use the new replacement for branches/
read the readme in the /Reinstall/ folder… it has instructions on how to use this new “easier system”
it looks like one real issue is caused by the upgrade to earlyaccess – but if this was a stable → stable upgrade, it wouldn’t cause problems… it only happens with 227 → reinstall → 253. if you 227 → upgrade → 253 or 253 → reinstall → 254+, it wont have reauthorize and slowness on first run.
i don’t think we are going to fix this for release, since its moot once you leave 227
Maybe I am misunderstanding that last rather terse comment 
but 227 was the regular 1.0 stable of Roon OS, right? I upgraded directly from this to 253 and had to reauthorize and slowness on first run.
Edit: Ah, of course the button in the web UI is “Reinstall”. I guess I just don’t get the difference between 227 → reinstall → 253 and 227 → upgrade → 253.
I experienced the same when upgrading.
Deauthorize always makes metadata improver stop working (been like this for years). You need to restart core once more to make it work. I would hope the latest Roon OS would solve this.
upgrade is what happens when you take it in roon, and reinstall is what happens with web ui.
you guys cant reproduce the upgrade case
Yeah my NUC 8i3 is now working fine on UEFI. it was just the deauthorise loop that caught me out.
if it’s picked up, then the bios isn’t doing a very good job of disabling it.
When I wrote that there was no file available…since then its been linked for download…so pre advice of these things might be a good idea for such things moving forward.
Roon wasn’t picking up the disabled HDMI Audio previously, on the same BIOS firmware.
Yeah – once I nuked the old partition, UEFI install went fine. Still running on UEFI now (NUC7i7).
Yeah, I saw – but the Help Center article link in the readme isn’t active yet, so that did not not help much. 
Strange … Linux is finding it
Yes, that’s why I was flagging it - has something been changed to add the UEFI support and has had a knock-on that affects the ALSA interaction, or whatever is controlling the HDMI Audio interfaces.
IIRC from the past, disabling a component in the BIOS was never the same as a hardware switch off. It mainly meant that the BIOS wasn’t reserving resources (memory, IRQ, …) for it. Older OSes respected the devices and (communication) resources allocated by the BIOS and used those as is. Later on and depending on an OS’s configuration, what the BIOS initialized was a must for booting up the OS and merely a hint for the OS itself. A modern OS could and often would run its own device detection and resource assignment – so disabled in BIOS devices showed up in the running OS (sometimes with the status “disabled”). With the current UEFI, the pre-boot-up UEFI and the OS became even more separate and it is often possible to see and change the UEFI BIOS settings for boot-up from the running OS – something that in the past was impossible from the OS and required a (re)start from the machine, entering the BIOS setup. So I’m not that much surprised. I don’t know the NUC hardware, but there are often pins on the mainboard that allow for disabling certain components which, when used, turn those components off.
Yes, working with 11th Gen Celeron N5095 in UEFI boot