Closed brunchboy closed 6 years ago
If anyone can help investigate this, I’d much appreciate, and can share the packet captures, too.
By sending status packets ourselves to the player we're querying (UDP port 5000), it will send us back all the metadata like normal.
I have no idea why yet, but I wanted to at least share.
What do you mean, exactly? Port 5000? I’m pretty sure that even when I have status packets turned on I still had the problem. But this sounds very exciting!
-James
On Oct 6, 2018, at 06:48, Evan Purkhiser notifications@github.com wrote:
By sending status packets ourselves to the player we're querying (UDP port 5000), it will send us back all the metadata like normal.
I have no idea why yet, but I wanted to at least share.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brunchboy/dysentery/issues/15#issuecomment-427567646, or mute the thread https://github.com/notifications/unsubscribe-auth/ACIChWnHlHA20nepFNh7Zz5PFI-_p7VMks5uiJirgaJpZM4WrBNO.
Whoops! Sorry it was late, port 50002 (there might be an extra zero in there, the usual port you would receive the CDJ status packets on)
So I am very intrigued by this, have you found a way to consistently get data? What values were you reporting in your status (i.e. did you have a track loaded, were you playing or stopped, etc.)?
And how often were you sending the packets?
Yeah, even when I have my status packet sender turned on, and it’s working in terms of letting me act as tempo master, I still get empty metadata responses for MP3 and AIFF tracks. Very mysterious and frustrating!
I just send this along with every keep-alive packet and it seems to work. Device ID is 2.
b := []byte{
0x51, 0x73, 0x70, 0x74, 0x31, 0x57, 0x6d, 0x4a, 0x4f, 0x4c, 0x0a, 0x43, 0x44, 0x4a, 0x2d, 0x32,
0x30, 0x30, 0x30, 0x6e, 0x65, 0x78, 0x75, 0x73, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
0x03, 0x02, 0x00, 0xf8, 0x02, 0x00, 0x01, 0x00, 0x02, 0x03, 0x02, 0x00, 0x00, 0x08, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xa0, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x04, 0x04, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x04, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x31, 0x2e, 0x34, 0x33,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x9c, 0xff, 0xfe, 0x00, 0x10, 0x00, 0x00,
0x7f, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0x00, 0x10, 0x00, 0x00, 0x00, 0x01, 0x00, 0xff,
0xff, 0xff, 0xff, 0xff, 0x01, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x10, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x30, 0x50, 0x0f, 0x01, 0x00, 0x00,
0x12, 0x34, 0x56, 0x78, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
}
Here's a quick screencast of what I've got going on: https://streamable.com/0pvwh
I've added this "fix" to my project. Though I still definitely don't understand why this is needed. Also it definitely seems strange that your status packets aren't working.
https://github.com/EvanPurkhiser/prolink-go/commit/c54fdfc69ff1aea557a668a19a22a4cc7106ac09
One thing I did notice is that bytes 0x68
and 0x75
in the status packet must be 0x01. In the analysis document one of these is noted as L
:
Byte 75, labeled L (for “Link available”), appears to have the value 01 whenever USB, SD, or CD media is present in any player on the network, whether or not the Link option is chosen in the other players, and 00 otherwise.
I still suspect that it's some kind of compatibility type thing.
Well, I’ll be… I just tweaked my status packet template to change some bytes to be the same as the ones you are sending, and suddenly I am getting metadata for MP3s and AIFF files too! I can’t understand why, and I am not sure I am going to devote the time to narrowing down which specific byte(s) matter, but this is awesome, thanks so much for helping me get over this hump, @EvanPurkhiser !
Actually, after eliminating a bunch of bytes that are things whose meaning we actually know, and are different based on actual status, I have narrowed it down to two potential bytes: 0x3a
where I was sending 0x00
and now send 0xa0
, and (the most likely culprit), byte 0xd7
where I was sending 0x00
and now send 0x01
. That was simply a mistake I made copying the template from dysentery to Beat Link, which may explain why I thought things were fine in dysentery, and then they did not work right in Beat Link.
Rats, we are not quite there yet! These changes are not enough. I still don’t reliably get non-empty metadata for non-rekordbox tracks until I turn on full sync mode and pretend to be playing a track myself. I need to look at what else that changes.
It turns out this was evidence of a bug in Beat Link! Fixed in https://github.com/brunchboy/beat-link/issues/20
Non-rekordbox metadata requests work great for AAC files (and WAV files seem to work no worse than what shows up on other CDJs), but MP3 and AIFF files give me back metadata responses with empty strings for all names (track, artist, etc). This is not the same kind of behavior I have seen where metadata requests fail outright, and I don’t get a response at all—I get back the normal 10 menu items I expect for non-rekordbox metadata, but the strings are all empty. And yet when the other CDJ tries to do the same thing, it actually gets the names. And I look at my packet captures side by side and I can’t see a single difference between my requests, which get back empty strings, and the CDJ’s requests, which get back good data.