I have my library splitted into multiples drives : E:\music, F:\music2 and g:\collection
Some playlist use files from all of these location.
I would like to cleanup and use only one drive.
I know and have no problem to edit engin sqlite database (I use it to rename path folder sometime) but I don’t know how to deal with this user case (and I don"t want to use external non-free tools)
If I move all my files into let’s say e:\music, e:\music2 and e:\collection how do I deal with databases? I have one Engine Library folder per drives with its own database.
sup @tAz-07 ! this sounds like a lot of fun to work on. It’s possible and will require some software to do it. I’ve not done this specific type of tooling, but I have written tools to manually copy an entire database schema record-by-record. The code can get pretty ugly. My Language of choice was Node & the Sqlite3 library, though tools like libdjinterop could/would make this much easier.
There is a lot to explain, and I’ll try my best. I’m only going to cover m.db, the main database for each storage volume. The history database hm.db will need to be considered if you want to merge those DBs. They will reference old data that will no longer be valid (E.g. songs in F:\music2).
Back up your Engine Library/ directories on ALL of your volumes (ALL your music storage devices & Host).
My favorite way of doing this is right clicking and a zip file, and naming it.
Let’s get to work (my latest understanding of the Schema is 4.0 as that’s what I use).
Assuming E:\ is the largest drive, I would approach it in the following way:
We’ll begin work using any one (uncompressed) copy of any of the music drive databases as a starting point & destination. EG: E:\Engine Library\Database2\m.db. Since E:\music exists and that database has records for it, we won’t need to do anything for those records.
The tables you’ll need to be concerned with are:
For Track Data:AlbumArt, Track
Each song you’ve entered into Engine DJ has a Track record, but not each Track record has an AlbumArt entry. Songs that have the same Album Art image data share the same AlbumArt record.
For Playlists:Playlist and PlaylistEntity. This stuff gets a bit hairy and takes time to understand.
The Playlist table contains all of the Playlists you see in Engine DJ on the left hand side Tree.
The Tree data is populated using the parentListId column. For example, each of the root-levelPlaylist records have a parentListId value of 0. Child Playlist records have their parentListId values of their parent Playlist.
Order of Playlist records are setup via the nextPlaylistId value. If records are not entered with a proper nextPlayslistId, Engine will not render playlists properly and may even delete records it deems are orphans.
The PlaylistEntity table contains records that reference the Track table entries and relate to a parent Playlist record. The native/default order of PlaylistEntity records is controlled by the nextEntityId column.
An approach to solving your problem would be:
Assuming F:\Engine Library\Database2\m.db (We’ll call F:DB) is the source & E:\Engine Library\Database2\m.db (E:DB) is the destination, I would do the following:
For each F:DB AlbumArt record, insert into E:DB AlbumArt, cache the old and new records. You may have duplicate AlbumArt entries (same albumArt (blob) & hash values), and that’s fine for now. you can always review them at the end to find duplicates. Cache the old and new record values because you’re going to need these.
For each F:DB Track record, insert into E:DB Track, and cache the old and new ids. For the new E:DB Track records, you can set the newly inserted AlbumArt.id values so that those new E:DB Track records have the correct AlbumArt associated.
We’ve inserted ALL of the AlbumArt and Track records, and associated them as required for the next step – Processing Playlist and PlaylistEntity records.
For each F:DB Playlist records, insert into E:DB Playlist taking into account the new record IDs and relate each newly childE:DB Playlist records to their appropriate newly inserted parents and set their appropriate nextListId values. Keep in mind that this is a tree of data and that Cache these records because you’ll need them for the next step.
For each F:DB PlaylistEntity record, you’ll need to copy those records to E:DB PlaylistEntity and associate them to their newly inserted E:DB Playlist records and sort them via their nextEntityId values.
It’s possible and will require some software to do it. I’ve not done this specific type of tooling, but I have written tools to manually copy an entire database schema record-by-record. The code can get pretty ugly. My Language of choice was Node & the Sqlite3 library, though tools like 