Corrupted DB Fixes?

Things are happening that make me think my Roon database is corrupted. The library reports 17 tracks for which there are no associated storage location. Half of my library (iTunes) has “uncurated” itself. (Okay I exaggerate. I BELIEVE the number of unfixed albums used to be at 200. Now it has jumped to over 400, most in the iTunes folder. Edited albums have become unedited. Art is missing. And this morning, my MBP remote could find endpoints (Oppo) but not play to it: a track could be selected but no sign of the playing process appears. (Restarting ROCK and remote has fixed the recognition problem.)

I have been paring my collection, deleting duplicate or inferior tracks. And in the Roon folder, I’ve been adding better rips. But nothing seemed out of the ordinary.

Next Step?

Running NUC Rock, 26000 tracks in two folders; iTunes folder seems troublesome moreso than Roon

This sounds more like storage instability, rather than database corruption.

Can you give us some more details about your setup? In particular, an understanding of your storage devices and configuration would be helpful.

Would be good to know exactly what you’re doing here, as well:

I have a NUC Rock (i7, 256SSD internal, 8TB external), and all files are on the external drive in two root folders: Roon and iTunes. I usually enable both within Roon Server. As I have re-ripped albums into the Roon side, I have deleted others on the iTunes side. And in general I have wanted to “curate” the iTunes side, which had gotten ill-kempt over the years. But all edits and deletions have been through Roon.

As a side issue, how dangerous/deadly is it to alter file names, move tracks, etc., using OS level edits? Can Roon handle those types of changes?

Mike, Should I rebuild/reindex/reimport my iTunes DB portion? Any further thoughts or advice?

Roon uses the audio data inside your files to track them. We should be able to track files (and their associated edits, playlist appearances, play counts, etc) if you move the file, or even rename it.

The biggest issue here is that if you copy a file somewhere else that Roon is watching, we will add the second copy to the database as well – obviously, there are cases where people may have the same file in two places, and we need to track both, even though the audio data in both is the same.

Note also that when you delete via Roon, the files are removed from the database, so edits and other information associated with the files will be deleted as well.

I’m just giving you some background about the pitfalls here – it’s still not 100% clear to me what the process is here:

So, if you have an album with some edits, delete it using Roon, and then copy the files back into one of your watched files, your edits will be erased.

If you have an album with some edits, and you first add a new copy and then externally delete the original copy, it’s possible the edits won’t be moved over, because Roon is now tracking two copies of the album since they were both added simultaneously.

Finally, if you have an album with edits and you want to preserve those edits but move the files to a new location, what you want to do is remove the files from your watched folder, and ensure they disappear from Roon. At this point the files will still be in your database with all your edits, but they’ll be “orphaned” – the files are missing. When you add the files in the new location (with identical audio content) the edits should carry over.

This process does a good job tracking files and edits, but it’s best effort – I’d recommend regular backups if you’re making lots of edits you don’t want to lose.

Again, this is just background info about how Roon tracks files. I don’t think the endpoint issues are related, and it’s hard to say whether the missing artwork is. More details about your process and specific examples of what’s “uncurated” will help.

Mike, possible breakthrough. Let me play it back: Roon makes no distinction which root folder a particular file is in; it will be all part of the same library once it’s somewhere in the Storage directory, yes? So while I thought of adding new higher quality rips from the “Roon Side” and deleting lower quality cousins from the “iTunes” side, there are, in fact, no sides at all. I got it (if what I said was correct). I’m not sure if that eliminates my concern but it sure corrects a mindset. Thanks for that.

But you haven’t addressed my question about reconstituting the database. To use a dated reference, we used to rebuild index files for large databases periodically to prevent or cure bad pointers. If I sensed my database/library collection was faulty somehow, is there any such remedy, or must one “start over”? And does one just Remove the folders from the Settings/Storage window, and then add them back? (I realize the edits and local artwork disappear with this process so I wouldn’t do this lightly.)

And two last terminology questions: Are an MP3 and a FLAC version of the same album considered “identical audio content” (your term from last post)?

Second question: when one deletes tracks with Roon, multiple warnings say things that convey a “lost forever” message. But that’s not the precise meaning, is it? You intend to convey, “Roon’s ability to access your files will be lost forever” but the music files will remain. To correct such a “delete” mistake, I imagine one would physically remove the files from the watch folder, then reinsert them. Pls correct/clarify as necessary.

Sorry, I ramble, but this changes my workflow. Thanks much for your patience. New frontiers for some of us. J

When files are deleted through Roon, the original audio source files are removed from your hard drive. In addition, all record of their existence is removed from the Roon database (I.e. edits are lost even if you drop an identical audio file in your watched folder from a backup location).

No, Roon separately tracks files of different resolution or in the presence of lossy compression. When everything works properly, these are treated as duplicate versions of the same album and the lower quality versions can be hidden automatically in most UI views (or not, as toggled in Settings—>General—>Show Hidden Tracks and Albums). I’m not certain if flac/alac/aiff/wav created from identical source data would be considered identical in the database.