Repository navigation
[XDJ-AZ] Missing DBServer 0x2d04 handler for extended PWV6/PWV7 analysis #91
Description
What problem would this solve?
[XDJ-AZ] Missing DBServer 0x2d04 handler for extended PWV6/PWV7 analysis
Description
Hi! First of all, thank you for the excellent work on Vynull!
I've been testing Vynull with my AlphaTheta XDJ-AZ (4-deck standalone DJ system) and maintaining a small custom fork called EXDJM.
After testing the official v0.6.0 release, I found a missing DBServer request handler used by the XDJ-AZ for extended waveform analysis.
I have a working fix that reuses the existing extended-analysis handler.
Environment
- Hardware: AlphaTheta XDJ-AZ (4 decks)
- Operating system: Debian 13
- Vynull: v0.6.0
- Upstream commit:
e93a391 - Custom EXDJM build:
502b3cb - Mode:
rekordbox - Connection: Ethernet / Pro DJ Link
Problem: unhandled request 0x2d04
The XDJ-AZ sends 0x2d04 requests when requesting extended analysis data, including PWV6 and PWV7.
With the official v0.6.0, the following appears in the logs:
TRACE dbserver msg type=0x2d04 txid=0000002d args=4
dbserver: unhandled type 0x2d04
args=[
0x01080401
0x00000033
0x36565750
0x00584532
]
The request containing 0x36565750 corresponds to the PWV6 tag.
Although the waveform may still be displayed using other available data, the extended request is not handled.
Proposed fix
File: dbserver/handler.go
Add the following case immediately after the existing 0x2c04 handler:
case proto.DBMsgGetWaveColor: // 0x2c04
return h.handleGetExtAnalysis(msg)
case 0x2d04: // XDJ-AZ extended PWV6/PWV7 analysis
return h.handleGetExtAnalysis(msg)This is a minimal change that reuses the existing implementation.
Results from my modified v0.6.0
After adding the handler, the actual XDJ-AZ requests are processed:
DEBUG dbserver: 0x2d04 track=48 tag="PWV6"
DEBUG dbserver: PWV6 for track 48 (3624 bytes)
DEBUG dbserver: 0x2d04 track=48 tag="PWV7"
DEBUG dbserver: PWV7 for track 48 (180724 bytes)
The fix has also been tested with another track:
DEBUG dbserver: 0x2d04 track=50 tag="PWV6"
DEBUG dbserver: PWV6 for track 50 (3624 bytes)
DEBUG dbserver: 0x2d04 track=50 tag="PWV7"
DEBUG dbserver: PWV7 for track 50 (89596 bytes)
The modified build passes go test ./..., and the XDJ-AZ successfully connects, browses the library and loads tracks.
Additional work: PSSI and phrase analysis
My EXDJM fork also includes modifications for phrase analysis:
- Dynamic PSSI generation from
r.Phrasesandr.BPM. - Optional structural phrase refinement to improve phrase boundaries and classification.
- Adjustments to ANLZ data generation.
- Additional waveform and NFS compatibility changes.
For example, PSSI is generated dynamically:
songStructure := prolink.GeneratePSSI(r.Phrases, r.BPM)
blob := analysis.WrapANLZ("PSSI", 24, songStructure)My current build confirms that PSSI data is served using the existing 0x2c04 request:
DEBUG dbserver: 0x2c04 track=48 tag="PSSI"
DEBUG dbserver: PSSI for track 48 (636 bytes, freshly generated)
The PSSI changes are separate from the proposed 0x2d04 fix. I'm still validating their behavior on the XDJ-AZ display.
Additional observations
The XDJ-AZ also sends other requests that are currently logged as unhandled, including 0x1400 and 0x3107. I have not yet determined whether these require additional handling.
Expected behavior
Vynull should recognize 0x2d04 extended-analysis requests from the XDJ-AZ and return the corresponding PWV6/PWV7 data using the existing analysis handler.
Actual behavior
Official v0.6.0 logs these requests as unhandled.
Contribution
I can provide the minimal patch or open a pull request for the 0x2d04 change.
Would you be interested in merging this compatibility improvement upstream?
Thanks again for your work on Vynull!
Proposed solution
:)
Alternatives considered
No response
Hardware context
No response
Before submitting
- I searched existing issues for a similar request.
- I understand Vynull is a hobby project with a deliberately narrow scope (a Linux Pro DJ Link source).
Activity
vynulldev commentedon Oct 16, 2026
Thanks for the detailed report and the patch, and for testing on an XDJ-AZ. Good catch
0x2d04was unhandled, it isn't only the AZ: the link-spec project's capture of an XDJ-RX3 talking to rekordbox shows the same0x2d04 [ctx, content, PWV6, 2EX]request, answered with a 3,624-byte PWV6, the same size your build serves. So any deck that shows 3-band waveforms probably sends it.One detail differs from the patch is that rekordbox does handle
0x2d04with the same code as0x2c04(itsGetSpecifiedAtomInfo), but every reply echoes the request's own kind: a0x2d04request gets a0x4f02whose first argument is0x2d04, including the not-found reply. The0x2c04handler writes a fixed0x2c04into its replies, so routing0x2d04to it as-is would answer with the wrong kind. Your AZ seems to accept that, but we try to match rekordbox byte for byte where we can.I have that version ready on a branch: it routes
0x2d04to the same handler and makes its replies echo the request kind, with a test for both kinds. Would you like to open the PR yourself? Since you found and fixed it, you're welcome to. Your patch plus the echo change would do it: inhandleGetExtAnalysis(dbserver/track.go), the replies' first argument becomesproto.ArgI32(uint32(msg.Type))instead ofproto.ArgI32(0x2c04). If not I can push my branch with credit to you. Either way, it would be great if you could try it on the AZ once it's in.On the other things you mention:
0x3107is rekordbox'sCMD_GET_FILTER_CONDITION_PROPERTY, one of its browse-filter commands, alongside0x3007(filter on/off), which decks send before opening the root menu. rekordbox's reply to it hasn't been captured yet, so we're leaving it unhandled for now.0x1400isn't in any request vocabulary I know of. If you can share its arguments from a--log-level tracerun, along with what you were doing on the AZ at the time, I'll take a look.0x2c04, so I'd be curious how yours differs and what the AZ shows with it. Feel free to open a separate issue once you've validated it on the display.Thanks again!
vynulldev commentedon Oct 18, 2026
Hey @przemeklo82 just a quick follow-up on the two other requests you saw the AZ send.
0x1400is the deck's SORT menu. When you press the sort button in a track list, the deck sends0x1400 [ctx, 0, list kind], where the list kind is the request that produced the list on screen (0x1004for TRACK,0x1105for a playlist). rekordbox answers with the sort options from its browse preferences (DEFAULT, ALPHABET, ARTIST, ALBUM, BPM etc.), and the deck then re-requests the list with the chosen sort ID. I was mistaken earlier to say it wasn't in any vocabulary, apparently link-spec lists it as the "Right Menu" request, and I've since captured real rekordbox answering it.I've added support for it in #100 and tested it on a CDJ-2000NXS2.
0x3107is one of the TRACK FILTER commands (0x3007to0x3407): it fetches the filter's conditions (BPM range, key, rating, colour and MyTags). I've captured rekordbox's replies to all of them and have the filter in PR #95 that I'm still testing. A deck that has filter settings saved also sends0x3207to set a condition, and without handling it the session drops; the branch fixes that too.If you get the chance to try either on the AZ once they're merged, I'd love to hear how they behave. The AZ's layout differs from a CDJ's, so it's a useful check.
vynulldev commentedon Oct 27, 2026
@przemeklo82 Just checking in, did you want to push a PR fix?
vynulldev commentedon Oct 27, 2026
@przemeklo82 I pushed PR #137 if you have time could you give it a test on your XDJ-AZ? Thanks!