M1 Mac Mini, 8GB, Mac OS 12.1, Roon 1.8 build 884. Database is on internal SSD, music files on external drive.
Networking Gear & Setup Details
Ubiquiti Unifi switches, Mac mini is connected by gigabit ethernet only.
Connected Audio Devices
RME ADI-2 DAC via USB
Number of Tracks in Library
150k
Description of Issue
Since upgrading to version 884 upon startup I get the “There was an issue loading your database” error. When I try to restore from a database backup as it suggests, it starts up normally but after scanning of the library is finished the screen eventually returns to the same “There was an issue loading your database” error.
I’ve tried this multiple times with different backups…
With the introduction of build 880 Roon introduced a mechanism to check the integrity of your database:
Database corruption means that the records Roon is reading out of your database are different from what was originally written. This is uncommon and can happen for a variety of reasons, including failing hard drives. In some cases, corrupt records can remain in the user’s database undetected for some time, only being detected when an update ships that requires Roon to scan every record in the database.
These updates occur infrequently, which increases the risk of data loss – if the user has opted to only keep a few weeks of backups, the chances they have a usable backup drop significantly if the “latent” corruption isn’t detected for many months.
Unfortunately it seems as though your current problem is a consequence of the issue outlined in the second paragraph above, i.e. the backups you have tried to restore from contain “latent” corruption causing the restore to fail. All I can suggest (as a fellow Roon user) is that you try to restore from an older backup if you have one - one that was created before the latent corruption was introduced.
If you have already tried this then there’s not much you’ll be able to do other than to start over with a fresh database, but I’ll flag @support so they can confirm.
Well I have spent today going back and trying to restore backups to no avail. Went back through many backups going back to version 831 in November, and after restoring all end up in the same place - “There was an issue loading your database” error. I then found an older one, version 814 from August last year, and it sort of restores but then the whole application repeatedly crashes.
It seems my only option now is to start from a fresh database and lose all my changes. I can’t even open my music now. I have to say, I am not happy with the whole way this has played out. There were posts going back into December about this issue that I see now, yet there was no warning upon upgrading.
I understand that this silent corruption has clearly been happening for a long time - Why? The Mac has been on a UPS 24/7. Why were no database integrity checks done over at least 6 months from 814 until now? I religiously kept scheduled automatic backups going back months for this reason and simply trusted Roon that the backups would be useable. Surely it is clear now that there needs to be some kind of manual database integrity check one can run, or optionally have it run automatically before backing up the database so you aren’t just backing up bad data.
If Roon became aware of this issue, why was there no warning or why was the update not pulled until some kind of database repair mechanism could be implemented?
If there is “some” corruption in the database, why can’t a new one be rebuilt using the “good” records, after those are individually integrity-checked, and only the “bad” ones omitted from the database and re-added fresh. At least that way you’d only lose changes on the corrupt records, not everything.
If I rebuild the database from scratch, won’t all the “date added” metadata all be set to today? What about all the playlists and favorites etc? Is that lost forever?
Most importantly… given it has now been demonstrated that silent corruption gets passed through to backups, how can I know that this isn’t ever going to happen again?
I consider this to be a significant failure and will find it difficult to trust this software again. I honestly can’t remember how many changes I made to entries directly in Roon, or to which albums/artists, it’s been over a period of years, but hopefully not too many.
I will say I am damned glad I continued to use a workflow that involved adding all music and making “most” (unfortunately not all) of the changes in iTunes first, which I continued to run in parallel, before it was imported to Roon, therefore most of the metadata changes should be picked up by a fresh database.
I remember people back then saying how ridiculous it was to do it this way and I should just add everything directly in Roon and make changes there because Roon’s database was much more sophisticated and was backed up automatically so you could never lose anything as you could always restore a database backup etc etc. I felt stupid still continuing for years to do most of the editing with iTunes when my playback was all through Roon. I do not feel stupid now… Had I not done it this way I would have had thousands, possibly tens of thousands, of tracks that needed manual editing all over again.
I guess I have no option now but to create a fresh database and add everything from scratch, unless there is some other way…
PS - Thanks for the advice anyway @DaveN, and for your other thread @freejazz
I can only imagine what it meant to take the steps you have — going through every backup you have all the way back to August — only to end up in the same place: there was an issue loading your database. I am so sorry. This shouldn’t have been the reality and I’d like to apologize for it happening to you…
Your questions are extremely reasonable and quite kind, especially considering the circumstances they stem from. I am grateful for that. I probably don’t have a good enough answer for all of them, but here is what I can say.
Integrity checks weren’t a strong suit of Roon before build 880. This means that certain parts of your database might have been corrupted, but, they were not exposed until… they were. This should not happen from now on, as Roon regularly scans your database and will inform you as soon as corruption is found (if any) so that you can restore the backup from just before that one.
It is understandable that you’ve lost some faith in Roon: we have broken your trust… . Before calling it quits, I wonder, would you be able to share a set of logs from right after you attempt to restore one of the backups? If you can also share with us the local date and time, that would make our job a lot easier. They can be uploaded in our drive.
Can we have some more information as to when, how often, or under which conditions the database scan now takes place? There appears to be no information in the user interface as to when it is running. Can one trigger a scan manually and receive information as to the result?
Also, regarding my question…
If I can get Roon up and running for a short while after restoring database backup (even if it subsequently finds database error, is there some way to quickly export playlists so that if I later create a completely fresh database I can then re-import those playlists? The playlists are going to be the hardest part to redo…
I have uploaded all the logs to the “our drive” link you posted above. The database restore failed maybe a minute or so before 10:54am on 21 Jan 22, times are GMT+3. ZIP filename is my username and email address.
If you are on a streaming service, you can export to soundiiz. Use sounding to import to a streaming service tidal or qobuz. Then import that back into Roon.
Thanks, that’s an interesting service I wasn’t aware of. But all my music in Roon is offline files, I don’t use any streaming services in Roon, the only one I have is Spotify for my phone and that’s not supported by Roon. Appreciate the info though.
Yes, I’ve never tried it, but, you could export the playlist to Excel and then mess around with it (especially renaming it) to put it into M3U format and then put that in your watched music storage area and see if Roon then picks it up. I know it does with Apple iTunes playlists.
You sure that works? I ask for such exporting features in some threads but nobody have had an idea.
In iTunes that was not a problem, I can agree. but I completely moved all to Roon a year ago.
You seem to have a more privileged access to information.
Maybe you also have an advice on how I should proceed to export an overview of my Roon albums as HTML or similar?
You should be able to select all (Ctrl+A or Cmd+A) albums, or really, just the ones you want and click on the three dot button that appears on the top bar and select export. Like so:
As much as I wish I did, I don’t have these answers for you, but I have taken them to the Roon team. We’ll follow up early next week when everyone returns to work. Please bear with us
And many thanks for the logs . They are with our technical team.
I only tried a little regarding the albums. Select all albums (CTRL+A) and you can export a list of your albums as CSV or XLS. But I did not find out a way for exporting a list of albums and its titles as a structure.
I have not tried that with playlists. Mine are gone since the 880 fiasco and the start with a new database.
Thanks for your patience over the weekend — I have hard back from the team and here are the answers we were looking for:
Database integrity checks are triggered with every backup. If the backup succeeds, the integrity check is successful.
And metadata for date added alongside all other data in the database (playlists, history, preferences, edits, etc.) is lost when starting from scratch…
Thanks for sending those logs over! The traces contained in your logs look a bit different than typical corruption, but rather you appear to be running out of file handlers on your Mac.
Can you please confirm how many tracks / albums you have in your library according to Roon’s Home screen? How large is your broker_2.db folder size under your Roon Database Location/Database/Core/(CoreID)? E.g. on Windows:
. Before calling it quits, I wonder, would you be able to share a set of logs from right after you attempt to restore one of the backups? If you can also share with us the local date and time, that would make our job a lot easier. They can be uploaded in 
