[Acknowledged] B1660 Feedback on migration process to new server and new authorization flow

[Suedkiez (Just a fellow user like you)]

Regarding:

@vova

Authorization flow

For years, our support team has spent a lot of time walking users through moving a Roon license from one server to another. The flow worked, but it was confusing and more than a little alarming – buttons that sounded irreversible, unclear defaults, and not enough reassurance that nothing would be lost. We’ve redesigned these screens to make the process feel like what it actually is: a straightforward move. We’ll keep a close eye on feedback here and refine further if things are still unclear.

I moved my ROCK to UEFI & RoonOS 3.0 and wanted to give some feedback to the migration process (as it was my first time) and re-authorization flow:

1. I followed the instructions to the letter. Generally this was easy because I use internal storage, so there was no messing with USB paths etc.
2. The KB guidance for the critical BIOS config settings for the NUC is appreciated and helpful. In addition, I think it would be helpful to add a recommendation to make a photograph of every BIOS config page before updating the BIOS, in particular if using a fanless device. I understand that Roon Labs can’t be responsible for specific machines’ necessary BIOS settings, but I think it’s worth pointing out that they exist and should (or must, in case of fanless machines) be retained. (The same hint should be in the ROCK installation instructions as well. In case you will provide UEFI instructions for OS 3.0 for older Nucleus, there should of course be complete step-by-step instructions for that).
   • On the Cooling page, the BIOS has a setting for fan behavior including a “fanless” option, which one surely wants to configure the same:
     
     
   • On the Power page, there are settings for Package Power Limit and Time, which control how long Turboboost is used. On my Cirrus7 fanless device, these were set lower by the manufacturer (as depicted) than the BIOS default:
     
     
   • One might have other settings that one wants to keep and it’s easy to forget.
3. The re-authorization flow on the new machine is certainly improved, but it was not 100% frictionless for me.
   • After booting the “new” (reinstalled) machine and starting the Roon app on the Macbook, I came to the log-in page where one is not supposed to log in but click Restore A Backup. OK.
   • The Restore A Backup link is still unchanged, i.e. too small, far at the bottom, and easy to overlook. It’s quite common on the forum that people overlook this and log in instead, which makes everything harder. Please make this more prominent.
   • Regarding what follows, it is important to note here that the KB states “Since this is your first time launching your new server, you will be asked to log-in. Instead of logging in, click “Restore A Backup” in the lower-left hand corner”. (In https://help.roonlabs.com/portal/en/kb/articles/migration#Step_3_Restore_Your_Database)
   • I clicked Restore A Backup correctly and was guided to the screen to choose the backup. OK.
   • The backup restored. OK.
   • Because of the “Instead of logging in” in the KB, I thought I would be done now, i.e., I would be automatically logged in.
   • However, I ended up on the Log In screen again (as before, with the Restore A Backup link at the bottom). This was slightly disconcerting as it felt as if something had gone wrong.
   • I chose to log in anyway, and everything was fine and my old, restored database available. (It was actually a bit better than expected: When I previously restored a backup, which I actually had done with the same B1660 right before performing the migration to confirm the validity of my backup, Roon first did some re-identification of a few tens or hundreds tracks for no obvious reason. After the migration & backup restore, it didn’t do this and everything was immediately fine).

Anyway, all set now with UEFI, OS 3.0, and nothing lost, so I’m happy

[Carl]

Tagging @beka can you discuss this with the Roon team please.

[Suedkiez (Just a fellow user like you)]

Somewhat related, the process of switching to a new server in the remote is still a bit scary to the uninitiated and could use some love:

On the first launch of a remote after the server migration, it can’t find the new server. Perhaps that’s unavoidable, but maybe it could discover all servers on the network right there? If it’s unavoidable, the small-print explanation could have some reassuring language in addition to „check that your Roon server is on“, like „this is expected if you made changes to your server“:

Then when you make the switch, there’s still the „you won’t be able to access the music you had before. Is this what you want?“. In my forum experience, this is often read as somewhat menacing and is what freaks people out the most. It needs a „just click yes, it’s fine“ reassurance post much too often:

Perhaps it could clarify:

• Some language that reassures that this is normal and expected because you can’t access music on a server as long as you’re not connected to it.
• If you are switching between more than one existing server, you can always switch back to the other one.
• If you migrated to a new server, you are just going to tell Roon to actually connect to the new one.

[ivan]

Hi, @Suedkiez, thank you for the feedback, I will pass it to the product team!

However, I have a question, about the backup you restored, how long ago it was created:

@Suedkiez

I clicked Restore A Backup correctly and was guided to the screen to choose the backup.

Thanks!

–
Ivan

[Suedkiez (Just a fellow user like you)]

It was a fresh backup into a new, separate folder, taken 5 minutes before starting the whole migration, with EA B1660.

1. Before migration, I created this new backup and restored from it again, to confirm its validity.
2. Then I performed the whole ROCK migration.
3. At the end of which, I restored from the same fresh backup.

[ivan]

Thank you for the response, @Suedkiez, we will investigate this behaviour locally.

Thanks!

–
Ivan