Deep-Symmetry / dysentery

Exploring ways to participate in a Pioneer Pro DJ Link network
Eclipse Public License 1.0
188 stars 24 forks source link

Crashes the XDJ-RX on connect #1

Closed pixelrock closed 6 years ago

pixelrock commented 8 years ago

XDJ-RX is recognized but crashes on trying to connect.

brunchboy commented 8 years ago

If you can send packet captures and the crash log, I may be able to do something about that.

brunchboy commented 8 years ago

Oh, you mean the XDJ-RX itself crashes? That’s mighty unimpressive. And would make it harder to find the crash logs.

pixelrock commented 8 years ago

yeah right, the XDJ-RX unit freezes :) can I do anything to help find the issue? Great work btw!

brunchboy commented 8 years ago

Thank you! Maybe you can help. If you (or a colleague) can reproduce it by plugging it directly into your computer, or have access to a switch or hub where you can mirror all the traffic that flows through the port it is connected to so it also gets routed to your computer, and you can perform and analyze network traffic captures. We need to figure out what it is doing when it crashes. My two top theories (flimsy as they are) are that it is reacting badly to something unexpected in the UDP packet that dysentery’s virtual CDJ broadcasts to announce itself on the network, or that it is trying to open a TCP connection to dysentery and freaking out that it can’t. A capture would help distinguish between those two cases.

Once we know which it is, we will know if we need to change something about the UDP broadcast, or add support for TCP connections. We may be doing the latter soon anyway, in order to be able to get access to track and title information.

So, assuming it is something about the announcement packets, then you’d want to start changing things about the packets and seeing if the crash still happens. Without logs from the XDJ-RX, or access to its source code, it is going to be a tough problem.

In the mean time, I will put a warning in the README telling people not to use this when they have an XDJ-RX on the network.

brunchboy commented 8 years ago

Another possible cause of the problem is that we skip right to sending announcement packets rather than the preliminary packets that are described in the analysis document. So we could try writing a version that sends those too, but that would be pretty tedious.

Or–and this would be awesome if it is true—do you know what Player number the XDJ is trying to use? Maybe the problem is that it is trying to be Player 5, and so is dysentery. The virtual CDJ in dysentery can be configured to use a different player number, but I didn’t expose that capability all the way out to running it from the command line, so if we think this is likely to be the problem, I could release a new version that makes it easier to run dysentery under a different player number, and ask you to try that.

pixelrock commented 8 years ago

Allright, will check ASAP. Can you recommend any network scanning tool for the job? Also I read that the XDJ-RX cannot link up with other CDJs, it can only use the Link to connect to recordbox running on a mac/pc. So maybe that's part of the problem? And that some Pioneer programmer forgot to catch an exception :) ?

brunchboy commented 8 years ago

Right, or just assumed that data on the network was always going to be identical with what they saw in their test environment, and didn’t check before trying to use it.

If the XDJ-RX can’t link or sync with other players then we are probably not going to be able to get much useful information from them anyway, but I appreciate your willingness to dig in to this a little bit. The network analysis tool I recommend is Wireshark, but be forewarned that this is a bit of a rabbit hole, once you start exploring and learning it, you might look up and wonder where all your time has gone! 😉

pixelrock commented 8 years ago

Well it links with the Rekordbox App, und you can play Tracks without USB straight from your Mac/PC – so I guess there could be useful information in there somewhere. Also possible that they just removed the user-facing aspects of linking to other CDJs.

brunchboy commented 8 years ago

Sure, I can do those things with the CDJs as well, they can even play music over WiFi from the Rekordbox app on my phone, which is a neat trick even if I would not quite trust it in a performance situation. But all of that media sharing is quite separate from the kind of beat and BPM synchronization that dysentery and beat-link are focused on. And for those things, even the CDJ 2000 gives far less useful information than the CDJ 2000 nexus. Which is why I suspect the XDJ-RX will give perhaps even less than the CDJ 2000, which is already of only partial use.

But we won’t know for sure unless we can find a way to avoid it crashing!

pixelrock commented 8 years ago

Ah ok I see! Yeah but also the 2000 is quite old, let's hope that's the culprit! Think I can check network stuff later, I'll let you know ASAP.

brunchboy commented 8 years ago

Agreed! And thank you, and there is no rush, I appreciate anything you can figure out.

maximevince commented 7 years ago

I can confirm my XDJ-RX crashes when launching dysentery, too. The whole UI freezes, and I have to reboot it.

brunchboy commented 7 years ago

Are you able to take network captures and figure out what it is trying to do when it crashes?

nudge commented 6 years ago

Hi @brunchboy, thank you very much for your work on this project, very cool! My XDJ-RX crashes when starting dysentery also, pretty much on receipt of the first packet.

I've captured some packets, see below:

Normal XDJ-RX turn on capture: https://www.cloudshark.org/captures/428ce9dc2d91

Normal XDJ-RX running, followed by starting dysentery: https://www.cloudshark.org/captures/964351253413

XDJ-RX: 192.168.1.13 (FW 2.20) Host running Wireshark: 192.168.1.6 (macOS 10.13)

I'll also do some digging and see if i can find anything!

nudge commented 6 years ago

Did some very rudimentary analysis of the normal turn-on packets, one thing to notice is that some of the previously thought static bytes differ for the XDJ-RX:

01 02 xxxx 01 CDJ 01 02 xxxx 02 Mixer 01 03 xxxx 07 XDJ-RX

Here is an annotated trace of the XDJ-RX turn on capture:

c0:a8:01:0d: <- IP address of the XDJ-RX
74:5e:1c:58:de:4a: <- MAC address of the XDJ-RX

1 [Device Startup]
51:73:70:74:31:57:6d:4a:4f:4c:
0a:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:25:
07

2 [Device Startup]
51:73:70:74:31:57:6d:4a:4f:4c:
0a:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:25:
07

3 [Device Startup]
51:73:70:74:31:57:6d:4a:4f:4c:
0a:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:25:
07

4 [Device Startup]
51:73:70:74:31:57:6d:4a:4f:4c:
0a:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:25:
07

5 [First stage device number assignment N=01]
51:73:70:74:31:57:6d:4a:4f:4c:
00:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:2c:01:
07:
74:5e:1c:58:de:4a

6 [First stage device number assignment N=02]
51:73:70:74:31:57:6d:4a:4f:4c:
00:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:2c:02:
07:
74:5e:1c:58:de:4a

7 [First stage device number assignment N=03]
51:73:70:74:31:57:6d:4a:4f:4c:
00:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:2c:03:
07:
74:5e:1c:58:de:4a

8 [Second-stage device number assignment, D=0b, N=01]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
0b:01:  
07:02

9 [Second-stage device number assignment, D=0b, N=02]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
0b:02:
07:02

10 [Second-stage device number assignment, D=0b, N=03]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
0b:03:
07:02

11 [Second-stage Mixer device number assignment packets, D=01, N=01]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
01:01:
07:02

12 [Second-stage Mixer device number assignment packets, D=01, N=02]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
01:02:
07:02

13 [Second-stage Mixer device number assignment packets, D=01, N=03]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
01:03:
07:02

14 [Second-stage Mixer device number assignment packets, D=02, N=01]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
02:01:
07:02

15 [Second-stage Mixer device number assignment packets, D=02, N=02]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
02:02:
07:02

16 [Second-stage Mixer device number assignment packets, D=02, N=03]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
02:03:
07:02

17 [Second-stage Mixer device number assignment packets, D=03, N=01]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
03:01:
07:02

18 [Second-stage Mixer device number assignment packets, D=03, N=02]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
03:02:
07:02

19 [Second-stage Mixer device number assignment packets, D=03, N=03]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
03:03:
07:02

20 [Second-stage Mixer device number assignment packets, D=04, N=01]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
04:01:
07:02

21 [Second-stage Mixer device number assignment packets, D=04, N=02]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
04:02:
07:02

22 [Second-stage Mixer device number assignment packets, D=04, N=03]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
04:03:
07:02

23 [Second-stage Mixer device number assignment packets, D=21, N=01]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
21:01:
07:02

24 [Second-stage Mixer device number assignment packets, D=21, N=02]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
21:02:
07:02

25 [Second-stage Mixer device number assignment packets, D=21, N=03]
51:73:70:74:31:57:6d:4a:4f:4c:
02:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:32:
c0:a8:01:0d:
74:5e:1c:58:de:4a:
21:03:
07:02

26 [Final-stage Mixer device number assignment packets, D=0b, N=01]
51:73:70:74:31:57:6d:4a:4f:4c:
04:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:26:
0b:01

27 [Final-stage Mixer device number assignment packets, D=0b, N=02]
51:73:70:74:31:57:6d:4a:4f:4c:
04:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:26:
0b:02

28 [Final-stage Mixer device number assignment packets, D=0b, N=03]
51:73:70:74:31:57:6d:4a:4f:4c:
04:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:26:
0b:03

29 Keep-alive [D=0b] (Apologies, this was cut off in the original packet capture)
51:73:70:74:31:57:6d:4a:4f:4c:
06:00:
58:44:4a:2d:52:58:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
01:03:
00:36:
0b:02:
74:5e:1c:58:de:4a:
c0:a8:01:0d:
01:00:00:00:07:00

[Packet 29 continues to repeat at 2 sec intervals]
pephumin commented 6 years ago

I also experience that my XDJ-RX also crashes when launching dysentery like others. I would really love to have dysentery to work with it, so please let me know if there is anything I can help on this.

brunchboy commented 6 years ago

It’s great to see that people with this hardware are starting to investigate this! If you can figure it out and come up with tweaks to dysentery which avoid this crash, we can update the protocol analysis, and pull them forward into Beat Link so that people can use Beat Link Trigger with the XDJ-RX. Another avenue you might want to investigate is the shortcuts that dysentery takes during the startup process. Austin Wright’s libpdjl shows a more complete implementation (in node.js). If someone could port that to dysentery it might also help.

brunchboy commented 6 years ago

Even short of porting libpdjl to dysentery, just seeing if it works on its own with the XDJ-RX would be interesting.

jine commented 6 years ago

XDJ-RX-Pioneer-link-Rekordbox.zip XDJ-RX: 192.168.1.102 (FW 2.21)

Wireshark between XDJ-RX <-> Windows 10 (Rekordbox), maybe can help someone?

brunchboy commented 6 years ago

Hey, @nudge thanks for sending that stuff! I’m sorry it’s taken me this long to take a look at it, I have been too busy with other projects, but it would be great to make some progress on this. CloudShark is a really cool resource, I had no idea it existed.

Looking at those captures you uploaded, though, it seems we are only seeing broadcast traffic from the RX. To really see what is happening with the protocol, it is necessary to use a managed switch, where you can configure the port that the RX is plugged into so that it mirrors all the traffic on that port to the port your Wireshark computer is plugged into. That way you can see messages the RX is sending to other devices as well. Is there any way you could try that?

brunchboy commented 6 years ago

Hmm. I just looked through the capture @jine sent, and it seems very different than what we would expect, it seems to connect directly to a rekordbox port without going through the normal player database server discovery process which would take place with a CDJ. I am starting to suspect that this player is designed to work with rekordbox only, rather than as part of a normal CDJ setup. Which would mean it will be unlikely to ever work with dysentery or beat-link, which emulate CDJs.

Oh, I just saw the following in a review of the RX2 which seems to confirm that suspicion:

Curiously, Pioneer DJ has opted for removing the Ethernet port at the back. This means no more link for those planning on connecting this to a bigger setup – although you were never able on the original RX when connected to CDJs. I think it’s a omission – as most people would be using the unit as is.

That implies to me that Pioneer does not support a mixed RX / CDJ setup, and have even moved away from Link entirely in the newer RX2. So I don’t think there is going to be anything we can do to make this work.

brunchboy commented 6 years ago

Indeed, from Pioneer themselves:

The LINK on the RX is ONLY for linking to rekordbox on your computer or a router with WiFi to connect rekordbox mobile. It can not exchange LINK data with other CDJs or DJMs.

https://forums.pioneerdj.com/hc/en-us/community/posts/203113059-xdj-rx-as-single-deck-on-pro-dj-link-

So, alas, this is never going to be possible. dysentery and related projects emulate a CDJ, and so cannot work with the XDJ-RX.