Bad thinking or bug?...and a warning to other Linux users

Not quite the same as I run a Rock, but I have often restarted without my NAS drive being switched on with no problems. Roon simply says the drive is unavailable but otherwise all is OK.

It sounds as though Roon thought it was a new machine. At that login prompt did you see a Restore a Backup option in the lower left corner? See the migration KB article for example.

As @xxx says, I hope you had a backup.

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.

Let’s see if @support has any input.

If what you say is true, a warning isn’t good enough and Roon should be involved.

1 Like

hi, what linux distribution do you use?

Hi @gduffield,

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.

Has your team tried to reproduce the issue or just assumed I don’t know what I’m doing?

@dylan, I ask again … Has your team tried to reproduce the issue or just assumed I don’t know what I’m doing?

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.

Any thoughts as to how the database could go missing in the situation I described? No changes were written to disk, the OS still booted, Roon still ran?

Seems someone else experienced a similar issue, albeit with an unavailable NFS mount. Related perhaps?

Tell me about your setup…

I don’t know what distribution you are running, if you used our installer, are running in a VM or docker instance, etc…

Where is your database located? What is that partition and how does it get mounted?

What’s in your database now? how big is it (du -sh <dir>)?

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.

do you have a copy of the “bad” folder in /var?

No, sorry, I killed it and ran the restore.

That’s unfortunate… and understandable.

Unsure there is anything we can do here now.

My guess is that something during the software update of Arch caused the Roon database in /var to get blown away. Unsure why it would do that, but that’s outside the domain of Roon.

If you had any record of what was in there, it would have been helpful in diagnosing whether it was corruption or deletion, but the lack of error points to deletion.

Are you running 5.x kernel?

There is a known issue with Roon scanning not finding all the content in a single scan, then losing and re-finding during the next scan with 5.x but no issue with 4.19.x.

May or may not be related to your experience.

I think the Linux 5.x issue you are talking about is probably related to audiolinux and not generically 5.x. I’ve been testing 5.x for a future Roon OS update without issues.

1 Like

Well, I wouldn’t be totally sure about the 5.x kernel… I upgraded my Roon only ubuntu 18.x LTS box to ubuntu 20.04LTS by a new install on a new NUC10. It was basically just a clean server install, no fancy packages except ssh. Ran into the not finding all the content in one scan and continuously dropping content and finding it again at the next scan.
Reverted to ubuntu 18 LTS on the same new NUC10,… problem gone.

I also created a message in the support category about this.

I have upgraded from 18.04 to 20.04 a couple of weeks ago. Difference is, I didn’t do a clean install but updated from the command line. Runs fine and didn’t have any problemas with finding the content.