Streaming via Pi and Cambridge Audio 851N, connected to Core via ethernet (through TP switch)
Number of Tracks in Library
~60k
Description of Issue
Reopening this issue – Migrated Core, NAS Storage, Playlists Now (Mostly) Empty – because I’ve bumped into again on a new, fresh Mac build. After having no resolution to the issue when I originally reported it, I had to give up on running MacOS and instead I installed Ubuntu Linux on the MBP and RoonCore on Linux for a few months, and life was good, completely stable. Due to a hardware issue I had to put MacOS back on the MBP for a bit so I thought I would test MacOS again. Bad idea. Here’s what I did and what I saw:
On Tuesday afternoon I installed a clean, fresh copy of Monterey onto the MBP (I opted not to use Ventura based on all of the issues that have been reported on this forum with the current version)
Installed RoonCore
Restored the DB snapshot that I’d made before wiping the Linux installation
Mapped my storage locations back to the external drive hosting all of my music
Life was good, playlists were fine all evening
Went to bed, woke up, fired up Roon in my office, checked the playlists, and they’re back to being wiped with the same UX as I saw last year: Most of the playlists have lost most of their songs, some are completely empty.
Tar’d all of the logs between when I installed RoonCore yesterday and this morning as soon as I came in and found the issue, so everything Roon did should be captured in those logs.
Here’s an example. The “Work Music” playlist yesterday immediately after installation:
The “Work Music” playlist after finding the issue again this morning:
This has affected all of my playlists, and I don’t understand why it’s happening and why it’s still happening, going from a perfectly clean and good DB on a Linux machine to 100% repeatable behavior on MacOS. It really hurts to see the issue still happening in 2.0. Is there anything I can do escalate this as blocker?
I was able to recreate it on Ventura, although it took 3 days for the playlists to be wiped out rather than overnight with Monterey (with the same amount of normal usage). So I’m still at a point where I can’t run my current DB on MacOS but it runs fine on Linux (stand-alone MBP and NAS).
UPDATE: Restoring the DB to a snapshot that I created immediately after restoring onto a new installation, when playlists were correct, doesn’t work to re-set the playlists.
I can always restore from the Linux snapshot I made immediately before wiping and re-installing MacOS, which does work to re-set the playlists, but it’s obviously not ideal b/c that restore requires me re-scanning my watched folders (because the paths change from Linux to Mac). The re-scan takes forever and it’s hard on the drives so it’s not something that’s feasible to do weekly.
This tells me something is happening to the way Roon is processing a fresh DB after the playlists are wiped out (for lack of a better way to explain my guess) on the Mac version of RoonCore. As previously mentioned I’ve run for years on a NAS without this happening (basically the same DB) and ran on Linux for months with no issue. It’s just MacOS with my DB.
Posting updates solely to keep the topic open so it won’t auto-close.
UPDATE: Now testing Linux Mint core on the MBP, just imported the good, clean, “master” DB from the Synology NAS (where the DB has been running perfectly for 3+years with no corruption issues) and scanned the local music directories, everything looks as expected after a clean restore ATM. Will keep this thread posted with updates on this new Linux core.
Specs of the new Core:
MacBook Pro
Linux Mint 21.1
3.5 GHz dual-core i7
16GB Memory
Core 2.0 (1244)
Database located on internal ext4 SSD (/var/roon/RoonServer/Database/):
Disk /dev/nvme0n1: 931.84 GiB, 1000555581440 bytes, 244276265 sectors
Disk model: APPLE SSD AP1024J
Music located on external ext4 USB drive:
$ sudo fdisk -l /dev/sda
Disk /dev/sda: 3.64 TiB, 4000787027968 bytes, 7814037164 sectors
Disk model: EXTERNAL_USB
A new record! The playlists were corrupted w/in an hour.
Well, I have officially exhausted all my available options. There was a part of me that was thinking that maybe a NUC would fix this, but seeing it four different OS’s now tells me it’s just a broken DB issue. Unless there’s a tiny, very tiny chance this is hardware related, but I can’t think of any way that the exact same, very specific, issue would be seen over and over due to hardware with different OS’s. I’m also hesitant to spend the days that would be required recreating my playlists from scratch b/c I’m not confident that this won’t keep happening.
@noris (or anyone in support): This is a hail marry before I pull Roon out completely and move over to Volumio, something I really don’t want to do: Any chance you now have a DB test/repair tool I can run in my environment? I view this DB as disposable so I’m happy to do anything to it locally that will fix/repair it.
I don’t have a broken env ATM to dig into. I replaced the OS on the MBP with LinuxMint and am in the process of manually rebuilding all of my Playlists rather than importing from the broken library versions, and so far it’s been fine, although I haven’t yet gotten to rebuilding the playlists. I can answer a few questions, though:
The files in the truncated playlists are a mix of sources and types. Some MP3s that would have been ripped and imported via iTunes years and years ago; some ALACs that would have been ripped in iTunes after I stopped ripping to MP3s but before I stopped using iTunes to rip; some ALACs that were ripped via XLD and originally imported into iTunes after I stopped ripping with iTunes completely; some FLACs that were ripped with XLD and imported directly into Roon after I moved from iTunes to Roon. These days I mostly purchase my music rather than rip it so the playlists would also contain songs from a mix of file types (depending on when in life I bought them, MP3s then ALACs then FLACs) and online retailers like Bandcamp, Nugs, HDTracks, etc.
tl;dr - A mix of all file types coming from local rips via iTunes and Roon and online purchases. I can’t ID any types of patterns about the truncated playlist contents.
None of the tracks in the affected playlists are corrupt; I can still play them directly without issue, and after doing a mass re-scan when I restore from a DB none of the files are flagged in Library → Skipped Files. It’s only the Playlists that “lose” the tracks; the source tracks are unaffected.
I don’t have a broken DB to upload ATM but I did previously upload one for @noris at a private link he provided. Perhaps it’s still available?
