when a new build triggers a DB issue and a downgrade removes it, roon should publish transparent information in this respect and review the code changes introduced with the new build.
How does one know that their database is corrupt? I believe that under some circumstances there are entries in the logs that indicate this, but for some issues, either restoring a database from a backup or starting afresh with a new database will fix the issue.
I recently had to start afresh with a new database due to an issue with my 3+ year old one. A restore didn’t fix the issue (ROCK server restarting every 3 days) but a fresh database did. A database issue yes probably but it was never diagnosed as such and the logs did not indicate corruption.
Hard to know. Such errors may sneak in (like after a system crash that seemed! not have harmed anything) and once you notice, it may have populated into every backup. In theory such a database could be repaired but often could come at an unreal price regarding the effort. This is what thorough db integrity or health checks may prevent in the first place.
This is part of the problem. Roon will quite happily back up a broken database I believe, without alerting the user. Without knowing which of the backups is a ‘good’ one, having multiple backups is pointless. If there are multiple database corruption scenarios, just starting over with a fresh one is the easiest way forward, but involves the most work if you have extensive tagging/playlists etc. None of this personalisation can be backed up and restored individually either, and will need to be recreated with a fresh DB.
I would assume too, but only Roon can tell us what measures they take. So my apologies if I head for the wrong direction. In any case publishing some more tech details or white papers would help the users to know about their risks.
Not sure how more knowledge about the DB would help though. Roon do not publish any DB checking utilities for users to run, nor would they support any installation that had been ‘fixed’ by 3rd party tools. They would be revealing too much IP giving out any details. To the vast majority of users, such information would mean nothing, they just want Roon to work, especially for ROCK/Nucleus owners, who expect an appliance to ‘just work’.
I’ve have not come across this before. What could I do? Right now I back up nighly onto a western digital my book that sits on my network all day. Is there anything else I could do to prevent or lessen the severity of a corrupt database?
I have organized my Library with lots of tags and Playlists, so I will do whatever to not have to do again
Roon officially recommend to do as many and distributed backups as you can. What we cannot influence is the quality of such backups, if db isn’t checked pre backup. In other words: garbage in garbage out.
For my backups I use a Western digital my book live. Its not a N.A.S. But it is on my network. So no raid abilities. Everyday at 2am, I have it set for backup.
I’ve just experienced this very thing. Having to rebuild my database using playlist in Tidal and library information from my old iTunes setup. It’s taken me 2 months to get something like back where I was.
Not wanting to go through this again, my Tidal account now mirrors the tags I have in roon, in effect giving me an external back up outside roon. I’m also planning to export track data into a CSV file for some extra piece of mind should my roon database fails again and the backups are corrupted.
The one thing that Roon need to fix is being able to add tags directly from imported Tidal playlists. That would make this a quick and robust alternative backup solution. Currently you have to manually retag within the main library. I’m not sure if they know this feature isn’t working since the 1.8 update.
