Big library (250+ tracks) exported USB not working on CDJ-350

[acrilique]

Hey so I've recently bought a couple of 2nd hand 350s and wanted to give a shot to the tool. I'm a developer so I thought I could maybe fix some issues if they arose.

First, I used rekordbox in a Windows PC to export my library which is just a replica of my Mixxx library in my Linux PC. The USBs I created this way did work perfectly with the 350's. After that, I removed the PIONEER and Contents folders from one of the working USBs and used rex to export my Mixxx library. This time, when plugging the USB to the 350, the text Library not responding appeared and the CDJ-350 USB LED kept blinking perpetually. Just to make sure this was not a formatting problem I re-formatted the same USB using the command in the README:

sudo mkfs.fat -c -F 32 -n label -S 512 /dev/sdX

And used rex again to export to it. When plugging this into the 350, the same message Library not responding appeared again.

So I'm currently scratching my head, as I see that some people managed this to work on CDJ-2000NXS2. Any ideas for troubleshooting? Thanks in advance. I'll start comparing the working USB with the non-working one using the analyze tool.

[acrilique]

I simplified my library to just 1 playlist with 1 track and that got it working! That must mean rex does something wrong when many files are exported at once (I was exporting 259 files).

Edit: after some analysis I think what's causing this issue is the missing indexes for the Tracks table. Indexes seem to be needed by hardware to quickly look up info without doing linear analysis of all tracks. This seems to not have been reverse-engineered yet, so it's an important limitation of the current software. These are all my own assumptions ofc.

[kimtore]

Hi @acrilique, thanks for testing and contributing. Indexes are as you have correctly guessed not successfully reverse engineered yet. Feel free to have a go at it. I am limited in my options as I don't have the hardware to test this.

[acrilique]

I will give it a try. If you have any advice about this I'd love to hear it (although I understand it's been a while since you last worked in this)

[kimtore]

I think the trick is to look at the data from the perspective of a ACID database storage engine, other than that I don't have anything useful right now unfortunately - as you mentioned, it's been a while. I can try to answer any questions you might have though.

[acrilique]

Here's the result of running analyze -index /path/to/usb/PIONEER/rekordbox/export.pdb with my working 259 track USB created with rekordbox: rekordbox-1-playlist-250-tracks.txt

I'm trying to find relationships between the values of Indexes and other stuff found in there. One thing I've seen is that if you shift the values of the Indexes (except the 1ffffff8 ones) 3 bits to the right, they all are equal to an idx in a Tracks Page. For instance, in my case:

Indexes: 0010 01c0 01d8 1ffffff8 0290 02a8 0248 0280 1ffffff8

• 0010 >> 3 = 0002
• 01c0 >> 3 = 0038
• 01d8 >> 3 = 003b
• 0290 >> 3 = 0052
• 02a8 >> 3 = 0055
• 0248 >> 3 = 0049
• 0280 >> 3 = 0050

These are all idx values of Tracks Pages with flags=34 and deleted=1 or more

This kinda makes sense, in the index.go file you left a comment saying: "for TRACKS and most other tables, there seem to be eight bits in use. The three least significant bits are always zero."

However it's unclear why not all tracks pages with flags=34 appear in the index. It's also unclear why they are unordered.

[acrilique]

For my investigation I have made a public gist to have all info there in a more polished format. I'll also try to mention this to the people working on crate-digger, rekordcrate and other related projects (although no one seems to be as interested as me in replicating the indexing)