Intermittent Rebooting of ROCK with Large Database (ref#T9UBJ6)

Support
44

Hello @alex_h @connor

The issue remains - it’s crashed twice

On examining the files in question neither were corrupted

After a reboot they both played fine

I now have another irritating problem - many Qobuz files will not play, and they become stuck until I move onto the next song. I have disconnected and reconnected my Qobuz account on a couple of occasions, but it makes no difference.

So now I have an expensive piece of software which is struggling to play not only my own files but also streamed ones.

Not very impressive really

45

This is a known issue that Roon are waiting for Qobuz on.

46

Hi @Ken_Talbot,

Thanks for the update! @MusicD is correct with the above; this is a known Qobuz issue upstream of Roon that our team is actively working on alongside Qobuz. Here is the tracking thread for this issue:

Is this occurring when accessing the same file? We can see from a fresh ROCK diagnostic file that the machine is simply running out of available RAM each time it crashes.

Have you considered increasing the RAM to 16GB?

48

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

· Unresolved issue dating back to Feb 8

Tell us about your home network

· https://community.roonlabs.com/t/intermittent-rebooting-of-rock-with-large-database-ref-t9ubj6/315148

49

@benjamin @vova @alex @connor @vadim @noris

It is far beyond time that you put me in touch with someone senior in your organisation - which I have asked for before.

This annoying problem remains - I have been on holiday so didn’t update the thread, so you closed it without checking

I have now replaced the RAM with a brand new 16GB one.- to no avail

Please let me have contact details for one of your directors

51

Hi @Ken_Talbot,

Thanks for writing back in, and I’m sorry to hear upping the RAM didn’t help your case. Please note that leadership has already been tagged and is aware of your case. We are discussing your issues internally and have it marked with priority.

From a fresh Roon Server diagnostic report, we’re still seeing confirmed OOM crashes, and the logs point to several compounding causes — with one in particular standing out as likely the primary driver.

Do you by chance have any overlapping watched folders active?

The logs show these watched locations on the Seagate Backup+ Hub:

  • Seagate Backup+ Hub BK : / ← the entire root of the drive
  • Seagate Backup+ Hub BK : /Music ← a subfolder of the same drive
And on the Sonnics USB 3.0:
  • New Volume, Sonnics USB 3.0 : /Music ← root music folder
  • New Volume, Sonnics USB 3.0 : /Music/A ← subfolder
  • New Volume, Sonnics USB 3.0 : /Music/Lawrence Rose ← subfolder
  • New Volume, Sonnics USB 3.0 : /Music/Hat Trick - Big Sky ← subfolder
The Seagate is watched twice — once at root / (which already contains /Music) and again explicitly at /Music. This means Roon is scanning and indexing the same files under two separate backends. The logs confirm this directly — every single file import shows two matching "deleted" records from two different backend UUIDs, and Roon is doing double the work to reconcile them on every rescan. With 63,000+ tracks, that's enormous overhead.

Combine that with sample rate upsampling to 384kHz, the DSP config shows the AURALiC VEGA G1 endpoint receiving audio upsampled to 384kHz / 32-bit. With the “max sample rate” conversion mode active, every track played is being upsampled. During playback this adds meaningful memory and CPU load on top of an already-pressured system.

A few next troubleshooting steps for you to try in the meantime:

  1. Check for any duplicated watched folders. Keep either the Seagate root / or /Music, not both. Same for the Sonnics subfolders. If /Music is already watched, you don't also need /Music/A, /Music/Lawrence Rose, etc. as separate entries unless those are on different drives. This alone should dramatically reduce memory usage during scans.
  2. Consider temporarily reducing the upsampling target, 384kHz is the maximum the VEGA G1 can accept, but if stability matters more than absolute quality right now, dropping to 192kHz or 96kHz during diagnosis would reduce playback load.
Let’s also clear the HTTP cache. Head to Settings → Setup → Clear Image Cache to help relieve the near-full cache situation.

Thanks for the ongoing patience here, Ken! :folded_hands:

52

Thank you so much @benjamin for your full reply

First let me say that I am an audiophile who is not at all tech savvy and so to be frank I don’t fully understand your response, so please take it very gently for me

I have 3 external databases on which I store (the same) music.

My main one is called “New Volume” but everything that I record onto this database I copy to a back-up one which is the Seagate. When this current problem started I wondered if the problem was the actual New Volume drive, so I disabled this and enabled the Seagate. However, the problem remained (I think that I can understand why from your email) when using the Seagate.

The SSK drive was a further attempt to understand the issue as it contains far fewer files but the problem occurs if a little less frequently

If I understand you correctly the issue could well be caused because in both the New Volume and Seagate drives all my music is in a subfolder called “music” so Roon is reading it twice. Altough this isn’t the case for the SSK drive.

I am most concerned to have the New Volume drive working properly again so I have already cleared the caches and reduced the upsampling. I will cut all the music files from the “music” file and paste them directly at top level in the database.

I’ll keep you posted as to what happens

Thank you

Ken

53

Sounds good @Ken_Talbot we’ll be monitoring for your reply and results!

54

Hello @benjamin

I am sorry to report that the problem remains just as before

On 12/5/26 at 20.55 (BST) I re-organised my New Volume database as agreed. Disabled the other databases

Rebooted 13/5/26 @ 18.45

Rebooted 15/5/26 @16.20

On this occasion I queried where the file was of the track playing when it rebooted - it said the SSK database when that database was not even enabled. So I removed the SSK database (not physically but in Roon)

Rebooted again on 15/5 @ 17.17

Rebooted 17/5 @ 13.46 and again @ 18.32

Rebooted 18/ @ 13.37 and again 21 mins later @13.58

Between each reboot I am re-installing Roon

This problem is a major issue with regard to my enjoyment of Roon

55

And rebooted @ 15.29

56

Hello @benjamin @vova @alex @connor @vadim @noris

I am disappointed to note that after 2 days I have not received a response to my last message to you. The least you could do is give me an update as to what you are doing to resolve it.

You say “Please note that leadership has already been tagged” - who is this person?

A message from them to me is long overdue

Your leadership team have no visibility to your customers - no accountability. Very poor bearing in mind the cost of the software.

Can you please describe your leadership team to me and how to contact them?

Who is this person - and I look forward to a message from them

57

Hey @Ken_Talbot,

Apologies for the delay here, our development team was able to review a fresh diagnostic report from your ROCK, and didn’t see any crashes over the entirety of the report.

How has your ROCK been performing as of late?

Some additional findings that you should be aware of:

Roon is still flagging 21 specific files as CorruptFile on the Seagate Backup+ Hub BK on every startup scan. Two are FLAC:

  • Music/Baker, Janet/Cleopatre/Meditation- Grands Pharaons.flac
  • Music/Baker, Janet/Cleopatre/Non!...Non, De Vos Demeures Funebres.flac
The remaining 19 are MP3s in the Frederick-Paul-Naftel-Orchestral-Chamber-and-Instrumental-Workd/ folder. These are being silently skipped by Roon at index time, but if they are queued for playback (e.g. via shuffle or a playlist that includes them), the audio pipeline attempting to decode them is a credible trigger for the OOM/segfault crashes previously identified on this thread.

With that, at 1am on June 8, the system hit 9.7GB physical RAM, this is while simultaneously running:

(a) the nightly Dropbox backup (confirmed at 01:00:00),

(b) the metadata update batch for the 49,511-item backlog, and

(c) database vacuum/validation.

GC pause times of 531ms are severe and indicate the .NET runtime is struggling to reclaim memory. Even with 16GB RAM, if multiple large overnight jobs converge, the system is clearly approaching its ceiling. Previous crashes almost certainly occurred when this tipped over the limit on the older 7.4GB RAM config.

Additionally, the SSK Portable SSD is still registered as a storage location in Roon even though it is disabled and physically absent (drive availability is: False). As noted in the thread, a previous crash showed Roon attempting to read from the SSK even when it was supposedly not enabled. The location entry itself should be fully removed, not just disabled.

The report also confirms that the AURALiC Vega zone has parametric EQ enabled with multiple active bands (including a +5.2dB low shelf and +5.5dB boost at 1264Hz), plus Audeze presets and speaker setup processing.

It was stated early in the thread that no parametric EQ or convolution was in use, this appears to be is factually incorrect per the logs. While EQ is not a primary crash driver, it does add DSP processing load and is worth flagging for accuracy. The custom sample rate conversion rule (96kHz → 192kHz) is also active, not the 384kHz upsampling previously discussed.

All of this said, Ken, here are some additional next steps that should potentially help you further:

  • Remove the corrupt files. Go to Settings → Library → Skipped Files. The 21 files listed above should appear there. Remove them from the watched folder entirely (or replace them with working copies). The two Janet Baker FLAC files and the entire Frederick Paul Naftel album on the Seagate are flagged corrupt on every boot.
  • Fully remove the SSK SSD storage location, not just disable it. Go to Settings → Storage, find the SSK entry, and delete it entirely. The ghost location is still attempting periodic access.
  • Stagger the overnight jobs. The crash window is consistently between 01:00–03:00 UTC, when the Dropbox backup, metadata batch update, and database vacuum all run simultaneously. Consider moving the Roon backup schedule to a different time (e.g. 04:00) to separate it from the metadata update window.
  • What DSP/EQ is set on the Auralic Vega zone? Since the report shows parametric EQ actively running.
Overall, the current session appears stable at a healthy ~1.8–3GB RAM during normal operation, which is reassuring. We’ll be monitoring for your follow-up and results, thanks Ken!
58

Thank you very much @benjamin for the work that you have obviously done to advise me here; it’s much appreciated

And yes the ROCK has not now rebooted since 1st June which is rather wonderful - so maybe just maybe you’ve sorted it. I have taken the steps you advise; I’ll let you know if it happens again.

Just for the record and in case it does happen again

The previous week to the 1st June ROCK would not work at all. Each track, whether from my database or Qobuz would play for a few seconds and then move onto the next track before stopping playing. So being totally perplexed I used a laptop as the core for about a week before going back to the ROCK with the Seagate drive again on 1st June

I actually have 3 drives where my music is stored i.e. “New Volume”, “Seagate” and “SSK”. New Volume used to be the drive I used with the ROCK. The other two were really back-ups for the music. Interestingly, although Seagate has the same number of files as New Volume ROCK finds about 10,000 less when it syncs with Seagate than it did with New Volume.

When I was using the laptop I took the opportunity to scan and fix all three drives with the Windows tool. Having reconnected both New Volume and Seagate ROCK does not find New Volume any more, but Seagate is running well as you know. From my naive perspective I wonder if the major problem all along has been a failing drive?

Many thanks for your efforts here

Best wishes

Ken

59

Hey @Ken_Talbot,

That is most excellent news!

This could certainly be the case - it was a really smart idea to scan the drives while you were already using the PC, great work there!

I’d like to clarify the above. So all 3 drives contain the same music, and you connect two of them (New Volume and Seagate) to your ROCK simultaneously?

If they contain the same library, I’d advise against this. I’d only connect a single drive hosting your local library to your ROCK at a time.

I’d be more than happy to continue to troubleshoot why the New Volume is not being recognized, but also, if Seagate is functioning normally and is hosting the same library, and you’re up and running smoothly, that’s great too! Let the show go on, so to speak :musical_notes:

Thanks again, Ken :folded_hands:

60

Hi @benjamin

Bit of a setback this evening @21.30 BST

It rebooted again

The only thing that I have done differently today that I have not done since Monday last week is to add three new albums to my database. Could this have been a factor?

Thanks

Ken

61

Hey @Ken_Talbot,

Thanks for the update! We took another look at a fresh diagnostic report, but we didn’t see a single reboot around the timeframe you’ve shared.

RoonServer logs a status heartbeat every ~15 seconds, and that heartbeat never stops anywhere on 06/15. Right through your reported reboot time:

  • 21:25, 21:26 … 21:30 … 21:31, 21:32 — uninterrupted 15-second heartbeats, no gap.
  • Memory steady at ~4,899 MB the entire window — flat, not climbing.
  • No out of memory, no exception, no segfault, no shutdown, no "Starting RoonServer" banner.
A genuine machine reboot would leave a multi-minute hole in that heartbeat followed by a cold-start banner. There is none at 21:30 (and none anywhere on 06/15). So whatever you saw at 21:30, the server process itself stayed up and healthy.

I’m sorry we’re not able to provide you with any additional context to what you experienced, Ken!

62

Hi @Ken_Talbot,

There are memory and performance improvements for large libraries undergoing testing in the Early Access category at this time (EA Build 2.63-2.65).

If you want to test these out, please follow these instructions to migrate your server and remotes to the Early Access branch:

63

Thanks, Connor - I’ve set myself up for the early access programme

Great to see that Roon continues to work on improvements