Yesterday I updated the Linux distribution on which I run Roon Server (it’s a rolling update so no reinstall is required). On rebooting the server it entered UEFI BIOS instead of booting Linux. I powered down the server and disconnected the directly attached drives containing music (a precaution to ensure I cannot inadvertently write to a music drive whilst recovering the boot drive). I then booted the server using a USB stick containing a liveboot instance of Linux so I could check the SSD’s function, partitions, filesystem etc. for integrity to find the issue.
A little online digging led me to understand that changes had been made to the EFI Boot Stub causing any forward slashes in the EFI Boot Stub string to stop working as before. After using Linux tooling to rewrite the BIOS’ EFI Boot Stub without the forward slashes I restarted the server, checking to see if it would now boot from the SSD that houses the server’s Linux OS and Roon Server + database. The server booted correctly and apart from the timeout messages regarding inability to mount the disconnected drives everything appeared normal, or so I thought.
I shut down the server, reconnected the power supply to each of the music drives and restarted the server. It booted and mounted the music drives without a hitch. All seemed well until I tried to run a Roon client and I was presented with a sign-in prompt a brand new virgin install would encounter - enter username and email address. Roon had effectively trashed the existing database for no apparent reason other than it on a single occasion encountered no content in the folders it looks to for content …
It’s hard to see this as anything other than poor software design. There was no reason to throw the baby out with the bathwater - a simple prompt to say “Your music folder(s) are empty, shall I expunge the existing Roon database or shut down and give you a chance to investigate?” would have completely avoided the need to rebuild or restore the database.
Lesson for Linux users: if your server hosting Roon plays up make sure you disable Roon Server before doing any troubleshooting. Roon is a rather blunt instrument!
The key difference (I think) is that in your case your system would be mounting a network share using SMB, whereas in my setup it was a local filesystem mount. It’s possible Roon understands when a SMB share is inaccessible but have not anticipated a local drive not being mounted in a Linux filesystem - the mount point would simply appear to be empty.
Roon would have shut down knowing there is content. On starting up again the content is gone. Time to enter limp mode and ask the user whether to start over or to check whether a drive or something else has failed. If it discards the database under these conditions I suspect it’ll do exactly the same thing for a failed NFS mount, because on the surface it’ll all look the same.
Even if your music files are available, Roon should not start with a fresh database. It seems like the RoonServer directory was unavailable or removed. As long as the database directory is still available there should be no change, regardless of watched folder availability.
I just unplugged the internal sata drive on a Roon OS machine sitting on my desk. No internal storage, no music. Rebooted with it plugged in, internal storage returned and so did my music.
No one made a comment insinuating any such thing. @dylan only explained that Roon is quite tolerant to having audio files missing. I know it is, because I wrote most of that code. The database, however, can not be missing.
not quite… he didn’t experience a db drop. in his case, the filesystem was missing, so all the music disappeared. when it came back however something changed (or a bug was triggered) causing it to think all the files were gone for good. Then when they returned, Roon had to rescan the files and once they are confirmed to be the same files as before, all the data will return too.
In your case, it looks like the whole db disappeared, not just the stuff about the files. The difference in symptoms being that you were logged out.
I’m not near machine now so can’t report database size and location, but the install was done using your standard install script and whatever it defaults to re storage location - I vaguely recall it’s somewhere in a /var subfolder tree.
Drive is a Samsung M2 SSD, formatted ext4, mounted via fstab, distribution is Arch on X64. The only change I made from liveboot was to the BIOS’ boot stub, nothing to disk.
A restore of a fsarchiver backup of the Roon subfolder tree in /var returned things to normal.