Hi Connor,
Quick note on my setup for context, since it’s relevant to the memory-pressure angle below: I’m running Roon Core on a Small Green Computer sonicTransporter i5 (no internal drive, purchased in 2019), streaming exclusively via TIDAL — no locally-stored library, no network shares. The only endpoint involved is a Lyngdorf TDAI-1120. Nothing about this setup changed around Jul 25 — no new hardware, no new shares, no imports.
Given this is the entry-level 2019 i5 unit rather than the higher-RAM i7/Gen3 models, I want to specifically rule in or out whether my hardware’s RAM allocation is simply undersized for my current library and usage — more on that below.
I went through the full log bundle and I think I found the actual trigger. Walking through it in order:
1. What happened at the moment of corruption
At 02:01:30 on Jul 25, the scheduled backup began validating the database. Six seconds later, at 02:01:36, the log shows a GC (garbage collection) pause of 5,117ms — meaning the Core process froze for just over 5 seconds. At 02:01:39, the instant it unfroze, two things happened in the same second: my Lyngdorf endpoint dropped its connection, and the validator threw “Source array was not long enough” — which is what triggered the DatabaseCorrupt flag.
2. Why that sequence matters
A 5-second freeze happening in the middle of a database read is exactly what would produce a torn/incomplete read — the validator was partway through reading a record when everything stopped, and picked up an incomplete buffer when it resumed. That would explain the corruption without requiring any external cause.
3. This wasn’t a one-time fluke
The same signature — GC pauses of 6,000–7,500ms, recurring every ~15 seconds for up to an hour at a stretch — shows up repeatedly in the days before this happened: Jul 24 from 1:05–1:59 AM, then again at 8:37 AM, 12:37 PM, and 4:36 PM, and again Jul 25 from 8:47–8:52 AM. Every one of those episodes also coincides with my Living Room zone getting destroyed and recreated — the same disconnect/reconnect pattern as the corruption event, just without a database validation running at that exact second to catch a bad read.
Conclusion: this points to the Core — running on this 2019 sonicTransporter i5 — periodically running under enough memory pressure that it freezes for several seconds at a time, multiple times a day. July 25th at 2:01 AM wasn’t a special event; it’s just the one time this recurring freeze happened to land during a validation pass instead of during normal playback, so it corrupted the database instead of just dropping a zone.
Given that, the trackid 17884584 metadata error seems unrelated — it’s been showing up in my logs since at least Jul 20, five days before the corruption, on its own separate schedule.
A few questions given this:
- Can you confirm this GC-pause pattern from your side and tell me whether it points to a memory leak, an undersized RAM allocation for my library on this hardware, or something else? Given this is a 2019 base i5 unit, I’d like to know if it’s simply underspecced for Roon’s current requirements.
- If the corruption really is a torn read from a single validation pass, is there a way to repair just that one record instead of rolling back to an older backup?
- What would you recommend to stop the underlying freezing, since restoring backups doesn’t address that?
Happy to send whatever else would help — just let me know.
Thanks,
Rohan
), confirm the system partition has healthy free space, then do the backup walk, restore your oldest backup, check for errors, and move forward one backup at a time until you find where corruption first appears. Everything before that point is your clean set.