One reason why I auto back up every morning at 2:00 am, and if I do a lot of changes of any type, I’ll do a manual backup.
I have 60 days of auto-backup but it is no solution for this issue, as 100% of your backups may be corrupt without roon even noticing.
I am currently stuck with build 764, which runs happily with my supposedly corrupt data whereas all subsequent builds are unable to load the DB.
This is a total mess, for which roon offers no solution whatsoever.
Is this really so? I ask because perhaps DB management is either performed in the background or unnecessary? Neither iTunes or Audirvana have a backup function, and I’ve never had a problem with those databases either. Roon has backup, but it’s obviously useless if it restores a DB error.
A ripped CD not appearing in roon may be linked to the use of unsupported characters in file names. Have you checked your files and tried to rename them?
Yes it is so. Unfortunately.
It is good that @danny has taken action Re.: DB checks, but this will only check before a backup is made. Most of the time this will be good enough as seen from Roon, but in a situation where a user is forced to restore the DB, a dedicated tool that can confirm the health of a backup would be of great value to the user. Keep in mind that a Roon user with a corrupted DB is probably quite stressed out so any help in the app itself is good (and you won’t have to wait for someone from support to help).
Agreed, a built-in diagnostic tool might be a very useful addition. Have you raised this in Danny’s thread?
This would only be valid for Nucleus/ROCK systems, but given that they are appliances, it would be a good place to start. There may be third party tools that could be used on Windows/MacOS/Linux systems?
No I haven’t. It’s a good idea. I’ll think about it…
Raising my (Nucleus + and lifetime subscription-holding) hand and saying, yes, something to auto-check that backups are good (or, useful, and the database is healthy) would be greatly valued. I’m today facing the second total database corruption since 1.8, and even though the backups run nightly, the last useful backup was two months ago, two weeks after the last complete database rebuild (not restore, that was useless).
Oh my! That is really bad! Let us hope @danny and @brian reads this. The DB backup/restore really needs some attention.
it’s in the roadmap
I’m curious to know (and maybe I’ll try it) if an auto-Roon backup is any different from a say, Chronosync verified backup (with Roon stopped).
I’ve tested the backups Roon makes, and never successfully Restored.
I have just briefly read release note for build 880. The improved DB handling is nice, but this:
the application will halt and the user will need to restore from a backup.
What!? No option to fix the offending DB record other than a DB backup? What if the available backups have errors in them? You’ll be getting nowhere and Roon has stopped - does not make sense to me. I’d want to know what is corrupt and get suggestions on how to fix it.
Maybe this works different in real life and it is good that Roon now has focus on DB corruption, but I hope this is only a beginning…
So this wasn’t a beginning. According to a post by @kevin this is Roon’s solution to DB corruption. I’d say this is not anywhere near a good solution. If you are so stu… that you haven’t got a working DB backed up somewhere you are on your own. NOTE: you have no means of knowing if any of your DB backups can be restored - until you try. If it doesn’t work, start with a new DB and loose all your edits, playlists…
For new Roon users (at or after 1.8 b880) the feature is good, but for us that have struggled through years of bad metadata this is not nice.
No it does work differently in real life. B880 reports database corruption on my Roon Core database. None of the backups I have are usable.
An “over a year ago” version on my backup ROCK server isn’t free of the corruption, so it is systemic going back years.
My Roon Core database represents 6-years of music management, Playlists, history - GONE
Prior to fold and start from scratch you maybe should reach out to Roon support and check if they have tools to at least try a repair?!
I have since I first experienced this issue, straight after the release of B880
They do not. I’ve been told by Support that there is no repairing, and no means to recover lost playlists or hearts.
No, I don’t believe there are any tools or processes been made available - there has been no activity on the tickets raised at the ticket with the B880 release. All references just quietly dropped by Roon.
Meanwhile I undertook a complete rebuild of my library on B880/B882, which took about a week to import and analysis.
I was then left with over 400 unidentified albums to work on - many of them should of been picked by Roon, but I am now down to 63 of 7013, and 3 of those are subject of a bug in the metadata identification selection, which it transpires has been there for many months and not yet solved.
I have also recreated most of my Playlists I had in Roon. This time, however, I have undertaken them as m3u8 based Playlists stored externally in a folder in my Music Library, so they are imported, so any future loss of a Roon database means I don’t lose them again.
Plus they can’t be changed or re-ordered from the Roon Remote application, unless they are copied as local versions (but still retaining the Library version).
All in all, it has taken about 2-months of work to recover from the corrupt database which halted operation of the B880 release.
I am making sure I backup regularly and in fact I am maintaining the database image over 2 ROCK servers, so I have an operational backup of my Roon Core incase a future Roon throws in new problems as half of the 1.8 releases have done.