How not to fix database design issues

When i learned about Engine [insert] 2.0 and it’s database refactoring, I had high hope what i though was the main design flaw would be addressed, sadly, it wasn’t. I guess I’ll have to wait for 3.0.

My main issue is how storage is done when having multiple drives. My music collection on my desktop is stored on it’s own drive (M:) while the main drive (C:) where the “main” EngineDJ db is stored.

What happens is that EngineDJ creates a library folder on the M drive (which still isn’t backed up by the software btw). So crates/playlists are still partially stored on either database depending on import path (ex: manually done vs itune import). You can see this info in the ‘drive’ column in EP.

Also, while it’s nice to be able to import back history playlists from an exported drive, it’s content is referenced through the ID on the exported drive UUID. So I imported back a historical playlist (yay) but then as I remove the SSD half the content is either RED (not found) or disappear altogether because it’s reference as being store on the SSD event though they all exists on my main drive.

A clear solution would be to move the “drive” subpanel at the same level as the itune / rk / tracktor icons and remove the “let’s merge all EP databases in the UI and confuse the hell out of everyone” behavior from EP.

I guess I’ll have to recreate my own database exporter/importer again.

Hello, your solution will be published on github or something like that, greetings

yeah, I already published a tool for fixing some stuff (ex missing file & duplicates) it need a better cli interface though. Right now it’s usage can be somewhat confusing.

haven’t tested on V2 database yet.

4 Likes