Music Library Corrupted: External NVMe, MacOS, Playlists on Standalone Device

So I’ve just had the moment that every DJ is eventually waiting for. Device Library corruption during normal operation.

All of my library is stored on an external NVMe (M.2 SSD) and accessed via MacOS. Engine Library is used in most recent version. I’ve had around 12.000 tracks sorted into three main playlists and 200+ sub-playlists.

During normal sorting process (external drive stayed connected) I’ve got an Engine DJ error popup saying that the device library is corrupted. Upon restart of Engine DJ, the problem persisted - playlists were still available, but no songs were listed. This persisted throughout a restore of the latest backup.

The restore seems to have been ineffective. When I connect the standalone players, though, I get back the library and playlists as in the state of the last sync (20+ hours ago).

The software does not allow me to sync from device to (empty) Mac, though, just the other direction:

The entire collection is just being listed on the players in respective artist / album sorting and it doesn’t appear to recognize that everything’s stored on the SSD as well. Is there a way to keep this a 20+ hour backup lesson (restoring from the players) or is this gonna be a 2+ year backup lesson (starting the library from scratch again)?

Anything to prevent this in the future? The NVMe had disconnected from time to time e.g. during train rides, but this time I was just sitting at my desk, sorting songs, when the “library corruption” error appeared and apparently nuked my last 2 year’s progress.

Take a manual copy of the relevant Engine Library folder and store that separately. I must have about 50 of them now. Also take two mirrored storage devices out with you.

Depends how you have Engine configured but there will be a way to backup manually.

Treat your performance drive as you would any other external drive

Make back ups.

FYI forum members in the UK cannot see images hosted on imgur.

Maybe a mod can edit the post and host the images here…

I have never had problems with my external SSD where I have the library, but a couple of weeks ago it happened that my SSD disconnected while Engine was open, now when I connect the SSD Engine takes more or less 10 minutes before detecting it, that is, it recognizes it but takes a while before seeing the playlists appear, I don’t remember if it started doing it because of that random disconnection, or after installing version 4.3.4! Do you recommend that I make a backup of the database folder? Because the backup with Engine has already been done!

Done. Sorry for the white outline. PNG seems to be auto converted to JPG…

2 Likes

Thanks for the replies and embedding the images. I haven’t fully given up on recovering, but am set on - at least now - implementing a proper backup strategy.

Is there documentation on how the databases are structured? In my Database2 folders, the m.db is by far the largest one, with around 25MB for the current version and around 8MB for the older one. The majority of this appears to be intact playlist data, but I can find absolutely 0 references to files, paths or folders. DB Browser for SQLite can open them just fine, and I’ve also followed Recovering Data From A Corrupt SQLite Database to generate SQL files and ‘recovered’ DBs.

I currently hope that the playlists are still existing, it’s just the external paths that are not recognized. Should any relative / absolute paths be stored in any of the database file - and if so, which one of them?

Here is a dump of the m.db database structure. The playlists and playlist entities are still intact, but all tracks are lost. Is there a way to re-scan the tracks and keep / restore / rematch them to the Playlist Entity data?

FILE: m.db

  • Table: Information | Rows: 1
  • Table: AlbumArt | Rows: 0
  • Table: Pack | Rows: 0
  • Table: Track | Rows: 0
  • Table: PerformanceData | Rows: 0
  • Table: Playlist | Rows: 1891
  • Table: PlaylistEntity | Rows: 72941
  • Table: PreparelistEntity | Rows: 0
  • Table: Smartlist | Rows: 0

It appears to be impossible to recover UUIDs for track entries as they appear to be randomly generated when importing. I was able to largely restore the database by copying the ‘m.db’ from the SC6000 in standalone mode and using a vibe-coded script to rewrite the paths, utilizing filename-based matching to my external drive. Some deduplication was also required - this solution is far from perfect, but saved around 10.000 tracks.

I’ve made the script available at Engine Library Restoration from Standalone Players - Pastebin.com . Note that this will only work in specific instances (as in here: playlist entries available, track information lost) and that no support can be provided for its use.

Lesson learned: backup yo’ library!

1 Like

With a properly coded library management software nobody should have to go through this.

1 Like

True. While a vibe-coded Python script is far from the quality expected from industry-implemented, widely deployed solutions, it left me a bit shocked at how little is available from Denon DJ / InMusic here for what’s apparently a well-known and widely experienced problem.

This at least got me to arrive at a proper backup solution, providing timestamped copies of the database and automatic adjustment of paths (incl. prefixes) to seamlessly migrate the databse between my Windows PC and Macbook sharing the same music library (stored on NAS).

Some more sophisticated database management, backup and recovery functionality within Engine DJ would definitely be worthy of consideration.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.