Roon server experiencing database corruption and duplicate entries post-update on 8/3 (ref#Q00Y4L)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· I have had Roon for 5 years. The last year my Roon server (logs show messages like this 08/06 11:07:32 Warn: RoonAppliance: caught SIGTERM (pid=2463) — default disposition will terminate) and will randomly cause my sonicTransporter to shut itself off. On 8/3, after the new update from Roon, the server lost connection with all my music folder and lost sight of the entire music folder. It shows no albums. Then, the sonicTransport reformatted the entire music SDD drive on its own.
I rebuilt the music drive from backups and then the next day it began re-adding all the flac folder albums to make double entries. The albums folder for flac albums where listed twice.
The Roon update along with what is likely a database corruption may be to blame.
I then deleted the Roon server and reloaded it. I rebuilt the Roon database from a recent backup (the only backup from after the recent Roon update was after the 8/3 reformat day). Unfortunately, the double entries are still there.
I could do an older backup, but I would need an older version of Roon server from you. Mike

Tell us about your home network

· AT&T router. Two Netgear 108 switches. No changes in my network for the last 5 years.

2

Hey @michaeljokich, welcome to the community, and thanks for the detailed write-up.

This sounds like two things may have happened together: the Roon Server stop/restart behavior on the sonicTransporter, and a library/database state issue after the 8/3 update and rebuild.

To get a clearer picture, we’d like to review a set of Roon Server logs from the ST if possible.

Can you please use the directions found here and send over a set of logs to our File Uploader? Once logs have been uploaded, please let us know so that we can check the server for your files, thanks!

3

I sent the files for review under my name.

Mike

4

Hey @michaeljokich,

Thanks for getting those logs over, we’ve been through them in detail, and they told us quite a bit.

Your database isn’t corrupt. We looked specifically for this, and there’s no sign of it. Your database opens cleanly every single time Roon Server starts, at the correct version, with no recovery or repair activity. There are also no disk errors of any kind on the music SSD, and no memory problems on the sonicTransporter.

So we don’t need to roll you back to an older Roon version or restore an older backup, the database you have now is healthy. What you’re running into is two separate problems that happen to have landed at the same time, and both are fixable.

Problem 1: Something outside Roon is stopping Roon Server.

In the roughly 4¾ hours your logs cover (the evening of 8/9), Roon Server was stopped and restarted 8 times, averaging about 18 minutes of uptime between restarts.

In every single case, Roon was working perfectly right up to the instant it was stopped. No errors, no slowdown, no memory pressure. One of the restarts happened in the middle of a track that was playing normally, 2 minutes 22 seconds into a 3 minute 38 second song, with a full buffer:

19:52:29 [PLAYING @ 2:22/3:38] Setting the World On Fire — Kenny Chesney / P!nk
19:52:30 RoonAppliance: caught SIGTERM — default disposition will terminate

SIGTERM is a shutdown instruction sent to Roon from outside of it. Roon isn’t crashing here, it’s being told to quit, and it’s complying cleanly each time.

One more detail worth knowing: your sonicTransporter itself never rebooted during any of this. We can tell because of how Linux numbers processes, the numbers climb steadily across all 9 restarts and never reset, which they would if the machine had actually restarted. So the unit isn’t shutting down or power-cycling. It’s the Roon Server service on it being stopped and started while the machine stays up.

Since the sonicTransporter’s own software (sonicOrbiter) is what manages the Roon Server service, that’s where the answer is. To pin down exactly what’s issuing the stop, we need a few things from the operating system side rather than from Roon:

  1. Over SSH (or however you normally reach the unit), the output of:
    • journalctl -u roonserver --since “-3 days”
    • dmesg -T | tail -200
    • uptime and last reboot
  2. Your sonicOrbiter software version
  3. Whether you have any scheduled reboot, auto-restart, or app-monitoring option enabled in the sonicOrbiter settings

And one question that might save us all some time: were you restarting Roon Server yourself from the sonicOrbiter web page on the evening of 8/9? If those were you, that’s useful to know, because it narrows the unexplained restarts down considerably.

Depending on what those logs show, Small Green Computer may need to weigh in with us, since this sits on their side of the setup.

Problem 2: The duplicate albums

This one we can explain precisely, and it’s a settings issue rather than anything broken.

Your Storage settings currently have /storage/music added as a watched folder, and nine folders inside it added separately as their own watched folders:

  • flac
  • Hi Rez
  • DVD-A
  • wav
  • DTS
  • Bluray
  • Qobuz Downloads
  • SACD DSF Multichannel
  • SACD DSF Stereo

Because /storage/music already contains all nine of those, every file on the drive is being found and imported twice, once by the parent folder and once by whichever subfolder it lives in. I confirmed this directly in the logs: every file I can see being registered under the parent folder is also being registered under one of the subfolders, with no exceptions.

That’s your duplicate albums.

The fix: In Settings → Storage, remove either the /storage/music entry or the nine subfolder entries, but not both. Keeping just /storage/music is the simplest option, since it already covers everything below it. Then run Settings → Library → Clean Up Library to clear out the leftover second copies.

One timing note: I’d hold off on this until we’ve stopped the restarts. Right now Roon can’t finish importing and analyzing your library because it keeps getting interrupted and starting over, your logs show the same background work restarting again and again and never completing. Some of what looks like missing or odd albums may simply be that unfinished pass. Once Roon can stay running for a few uninterrupted hours, do the storage cleanup and let it settle.

With that, your backup location contains backups from two different machines, this sonicTransporter, and another machine. Can you tell me which backup you restored on 8/3?

Two small housekeeping items

  • One damaged file. Roon is skipping this one because it can’t be read: Hi Rez/Skid Row - Skid Row (30th Anniversary Deluxe Edition) (2019) [FLAC 24-96]/07 Youth Gone Wild (Remastered).flac. Worth re-downloading or re-ripping that track. It’s the only unreadable audio file in your entire library, which is a good sign for the drive overall.
  • About 77 artwork files in .bmp and .tiff format sitting inside album folders (in the Elton John and Moody Blues folders, among others) that Roon can’t load. Completely harmless, Roon just skips them, but that’s what those warnings are if you ever spot them.

Where that leaves us

  1. Send the operating system logs and sonicOrbiter details above, that’s the one open question, and it’s the one causing the disruption.
  2. Once Roon can run uninterrupted, fix the overlapping storage folders and run Clean Up Library. That resolves the duplicates.
  3. Let me know which backup you restored on 8/3.

I know this has been a frustrating stretch after five years of things working. The encouraging part is that your library and database are intact, we’re chasing something stopping the service and a settings overlap, not data loss. :raising_hands:

5

Yes. That was me.

6

I will do the rest and get the sonicTransport info to you.

Thanks for your help. Roon support has been great!!

Mike

7

Hello @michaeljokich

That answers the biggest open question, and it saves you some work.

Since those restarts on 8/9 were you, we do not need the operating system logs after all. Please leave that request aside unless the unit powers itself off again.

It also means you can go ahead with the storage fix now rather than waiting:

  1. In Settings → Storage, remove the nine subfolder entries and keep only /storage/music, or the reverse, but not both.
  2. Let Roon finish its import and analysis without restarting the server. Please give it a few uninterrupted hours.
  3. Then run Settings → Library → Clean Up Library to clear the leftover second copies.

Once the storage change has settled, please tell us how the library looks and we will take it from there.

8

The Roon server continues to shutdown often. One day, it shut down over 3 times randomly with the Sigterm code in the log right before shutdown. I am trying to get the owner of Small Green Computer to tell me how to get the log off the sonicTransport to get to you.

Thanks again,

Mike

9

Hey @michaeljokich,

We also agree that getting the SonicTransporter logs off the unit and to us and small green computer for review is a good step.

You can get the logs by going to

and navigating to Manage, then Apps, then Roon. Please send those logs to our uploader as soon as you have them:

https://workdrive.zohoexternal.com/collection/nocvrfc5b2ddab55140af8640f1d7ce13291e/external

Once we have them, let us know and we can take the next step from there.

10

Those were the type of logs I originally sent, the Roon server logs. One of your other support people wanted the logs off the sonicTransport operating system or sonicOrbiter. Those, I am trying to get and don’t know how to access them. He believed the sonicTransport was causing the Roon server to shutdown and occasionally even causing the sonicTransport to shutdown randomly.

Mike

11

Hello @michaeljokich

Thank you for the update.

Here is exactly what our logs can and cannot tell us.

They show Roon Server being shut down cleanly. It receives an instruction to stop, called SIGTERM, and it complies properly:

RoonAppliance: caught SIGTERM (pid=2463) — default disposition will terminate

That happens while Roon is working normally, in one case mid-track with a full buffer. Roon is not crashing and it is not failing. Something outside Roon is telling it to quit.

What our logs cannot record is what sent that instruction. That information exists only in the operating system on the sonicTransporter, which is sonicOrbiter, and that is Small Green Computer’s software. We have no access to it and we would not be able to interpret it. So you are doing the right thing by going to them, and there is nothing further we can extract from our side.

Please also mention the separate matter of the unit itself powering off on its own, since that is squarely theirs too.

If they come back and say the cause is on Roon’s side, post what they tell you here and we will pick it up again.

14

Hi @michaeljokich,

We received your request to reopen your recently closed support thread. Please run through the latest troubleshooting steps listed above, and we’ll be monitoring for your reply and results.

Thank you!

15

Since my last post about my problem, over the last two weeks or so, I had to restart the sonicTransport i7 4-5 times, and the Roon server would shut down randomly 10-15 times or so in between the sonicTransport shutting itself down, also randomly. I never shutdown the sonicTransport nor did I stop the Roon server. No power outages have occurred. I just restarted the i7 again and opened Roon for the first time (the other shutdowns I just restarted the sonicTransport without opening Roon on any device), and I noticed my Music folder and subfolders/files completely erased themselves on their own once again.

I added the logs for your review, which I will send to the uploader. Look at log #12 ending on 8/19 at 5:45AM, at 8/17 at 20:55, the Music folders suddenly go off-line for no reason in the Roon log. Roon then states dispose!! and starts getting rid of tracks in the database, I believe. Roon shouldn’t be able to actually erase the data on the drive, right?

Thanks

Mike

16

Hello @michaeljokich

Thank you for the update and for uploading the fresh logs.

I want to address your primary concern immediately: no, Roon does not have the technical capability to physically delete or erase music files from your hard drive. Roon operates in a read-only capacity regarding your core music storage directories; it can manage metadata, playlists, and internal database indexes, but it cannot format drives or delete source audio files.

If your music folders and subfolders are physically erasing themselves or disappearing entirely while the device is running, this points directly to a hardware-level or file-system-level failure on the sonicTransporter i7 itself (such as drive corruption, a failing internal storage controller, or an automated filesystem maintenance script on the sonicOrbiter OS formatting the drive).

The fact that the sonicTransporter i7 is also shutting itself down randomly without your input—combined with the automated drive reformatting you originally experienced on August 3—strongly confirms that the underlying hardware or the sonicOrbiter operating system is encountering critical storage or power management faults.

Since Roon cannot write to or delete your source files, you will need to share these specific findings with Small Green Computer. Specifically, let them know that the storage partition is erasing itself even when Roon isn’t running, as this indicates a hardware or OS-level storage failure that they will need to troubleshoot on the sonicTransporter.

Please let us know what Small Green Computer says after you share this with them.