SSD DJ Library Corruption After Transfer

I’m having an issue that’s now happened twice over the last two years. After moving songs from my Engine library to my SSD, I got a packing fail error message, and then immediately it says database became corrupt. This was after successfully transferring tracks for about 30 minutes with no issues.

I can still see my history, but all my playlists and the full collection are gone from the SSD. The drive still shows that space is being used, but no files appear. I tried running First Aid repair (Mac) with no luck.

The SSD is a Crucial MX500 1TB. This was a routine transfer moving songs over to the ssd inside my sc6000 into a dedicated playlist, something I do weekly without problems until now.

Any ideas on what’s causing this?

Engine DJ 4.2.1 Sc6000 4.2.0 M3 Max - Sonoma 14.4 Crucial MX500 1tb USB cable from Mac to sc6000 for transfer

UPDATE! Max Character Limit. I ended up using terminal on mac with a few prompts to help me find the longest titles. In lexicon and engine os shows a shortened version but the actual file was really long. So I cleaned them up from the actual file and imported them again making sure the original named file is deleted and it transferred no problem to my ssd.

1 Like

Oh that’s not fair! You’ve not completed the story. If you were hitting a max character limit, what were you using as file names? Give us an example. :thinking:

Not sure if this is relevant, but if I remember right, I had a similar issue in Rekordbox, one track that was named wrongly or by itself was corrupted, it couldn’t be analyzed, so analyzing tracks in whole collection was stuck, and exporting files to external storage was also stuck, but it had a waveform in Rekordbox.

So what helped me to find the specific track was bundle analyzing files playlist by playlist, and then when I’ve figured out which playlist contains such song, I’ve then was analyzing track by track and got to that one song. If my memory is correct, it had a proper filename, and I can’t state for sure if I had issues at that time exporting that song from Engine DJ to external drive.

Why I’m giving this example is because if you have this issue that you’ve described, you can try to find that track as I did.

Also, it might be that file transfer was interrupted rather by cable being disconnected for a second or the SSD going to sleep at some point, that’s my guesses. Also, for database not getting corrupt, if it is possible, check (or format) your external storage to a MBR partition using a partition formatting tool (like Rufus), because if it is in GPT format, then the database will get corrupted as Engine OS has issues with such partition style. This is not same as Fat32 or exFAT or NTFS formats, that’s why only using a specific tool you can change that (not sure if the Windows Device Manager setup wizard is able to do it, but anyways you have Mac)

This is the track that did it. I used it for an event a while ago. A few live symphony songs, and somehow it never caused problems until now. Grateful it didn’t crash everything right before an event. Title alone is 255 characters.

The maximum file path length Engine DJ supports on an SSD (or USB drive) is 255 characters total, which includes: • The full file path (folders + file name) • File extension (e.g., .mp3)

Ah yes, I see the issue! Standard format is Artist - Title but your file name contains other info that really should live in the ID3 tags.

2 Likes

This could be raised as something for improvement as although the likelihood of it causing issues to a lot of people are very low, they could be better messaging around why it’s happened.

The software realised it couldn’t complete the task. Could a dialogue box explain this more clearly? Maybe offering advice like shortening the affected file and retrying?

Just a very small QoL update that explains why something happened and any possible steps to rectify would be a good feature request. Some users may not know there’s a limit so being presented with an ordinarily normal ID3 tag in the Engine DJ software may be a headache when in reality it’s an extraordinarily long file name tripping it up. Database borking isn’t fun.

3 Likes

This certainly makes me wonder where in the pipeline the limitation exists as the Track table’s path column (where the full file’s path is stored), is setup as Text, and Text has the default max length of 2,147,483,647 bytes.

Also, QString class in modern architectures have a max length much larger than 255.

CREATE TABLE Track ( 
	id INTEGER PRIMARY KEY AUTOINCREMENT, 
	playOrder INTEGER, 
	length INTEGER, 
	bpm INTEGER, 
	year INTEGER, 
	path TEXT, 
	filename TEXT, 
	bitrate INTEGER, 
	bpmAnalyzed REAL, 
	albumArtId INTEGER, 
	fileBytes INTEGER, 
	title TEXT, 
	artist TEXT, 
	album TEXT, 
	genre TEXT, 
	comment TEXT, 
	label TEXT, 
	composer TEXT, 
	remixer TEXT, 
	key INTEGER, 
	rating INTEGER, 
	albumArt TEXT, 
	timeLastPlayed DATETIME, 
	isPlayed BOOLEAN, 
	fileType TEXT, 
	isAnalyzed BOOLEAN, 
	dateCreated DATETIME, 
	dateAdded DATETIME, 
	isAvailable BOOLEAN, 
	isMetadataOfPackedTrackChanged BOOLEAN, 
	isPerfomanceDataOfPackedTrackChanged BOOLEAN, 
	playedIndicator INTEGER, 
	isMetadataImported BOOLEAN, 
	pdbImportKey INTEGER, 
	streamingSource TEXT, 
	uri TEXT, 
	isBeatGridLocked BOOLEAN, 
	originDatabaseUuid TEXT, 
	originTrackId INTEGER, 
	trackData BLOB, 
	overviewWaveFormData BLOB, 
	beatData BLOB, 
	quickCues BLOB, 
	loops BLOB, 
	thirdPartySourceId INTEGER, 
	streamingFlags INTEGER, 
	explicitLyrics BOOLEAN, 
	activeOnLoadLoops INTEGER, 
	lastEditTime DATETIME, 
	CONSTRAINT C_originDatabaseUuid_originTrackId UNIQUE (originDatabaseUuid, originTrackId), 
	CONSTRAINT C_path UNIQUE (path), 
	FOREIGN KEY (albumArtId) REFERENCES AlbumArt (id) ON DELETE RESTRICT 
);