Menu Requests

We have already seen many examples of the menu mechanism in action, most clearly with metadata requests, track list requests, and playlist requests. We’ll round out what is known about the other types of menu request here.

The overall flow starts off by sending a menu request message whose type identifies the kind of menu desired (in the message type field), along with some parameters that control the specific content to be shown, and perhaps establishing a sort order. See, for example, a playlist request. If all goes well, the player responds with a packet with type 4000 like this one, containing two numeric fields that hold the original menu type value you requested, followed by the number of menu entries that are available for you to load.

To actually obtain those menu entries, you send one or more “render menu” request messages with type 3000, allowing you to paginate through the results. This gets you a number of responses: a menu header message (with type 4001), followed by the number of menu item messages you requested (with type 4101 and the content described in Menu Item Types), and finally a menu footer message (with type 4201).

Known Menu Request Types

The table below shows the menu requests we have figured out so far. Not all menus are available in all rekordbox databaes; the DJ can decide what indices and categories to include, and that will determine which of these requests succeed. To find out what is available, you can request the root menu, which gives you access to all available menus. That is what a player will do when you use the Link button to connect to media mounted on another player. The menus available to you will be returned as entries in the root menu response, with Item Type values in the range 8095, as shown in the known menu item types table.

Table 1. Menu request types.
Type Meaning Arguments


Root Menu

r:m:s:t, sort, 00ffffff


Genre Menu

r:m:s:t, sort


Artist Menu

r:m:s:t, sort


Album Menu

r:m:s:t, sort


Track Menu

r:m:s:t, sort


BPM Menu

r:m:s:t, sort


Rating Menu

r:m:s:t, sort


Year Menu

r:m:s:t, sort


Label Menu

r:m:s:t, sort


Color Menu

r:m:s:t, sort


Time Menu

r:m:s:t, sort


Bitrate Menu

r:m:s:t, sort


History Menu

r:m:s:t, sort?


Filename Menu

r:m:s:t, sort?


Key Menu

r:m:s:t, sort?


Original Artist Menu

r:m:s:t, sort


Remixer Menu

r:m:s:t, sort


Artists for Genre

r:m:s:t, sort, genre ID


Albums for Artist

r:m:s:t, sort, artist ID


Tracks for Album

r:m:s:t, sort, album ID


Tracks for Rating

r:m:s:t, sort, rating ID


Years for Decade

r:m:s:t, sort, decade


Artists for Label

r:m:s:t, sort, label ID


Tracks for Color

r:m:s:t, sort, color ID


Tracks for Time

r:m:s:t, sort, time


Tracks for History

r:m:s:t, sort, history ID


Distances for Key

r:m:s:t, sort, key ID


Albums for Original Artist

r:m:s:t, sort, artist ID


Albums for Remixer

r:m:s:t, sort, artist ID


Albums for Genre and Artist

r:m:s:t, sort, genre ID, artist ID[1]


Tracks for Artist and Album

r:m:s:t, sort, artist ID, album ID[1]


Tracks for BPM +/- %

r:m:s:t, sort, bpm ID, distance (+/- %, can be 0-6)


Tracks for Decade and Year

r:m:s:t, sort, decade, year[1]


Albums for Label and Artist

r:m:s:t, sort, label ID, artist ID[1]


Tracks near Key

r:m:s:t, sort, key ID, distance


Tracks for Original Artist and Album

r:m:s:t, sort, artist ID, album ID[1]


Tracks for Remixer and Album

r:m:s:t, sort, artist ID, album ID[1]


Tracks for Genre, Artist, and Album

r:m:s:t, sort, genre ID, artist ID[1], album ID[1]


Tracks for Label, Artist, and Album

r:m:s:t, sort, label ID, artist ID[1], album ID[1]


Playlist Menu

r:m:s:t, sort, playlist or folder id, type (0:playlist, 1:folder)


Search by substring

r:m:s:t, sort, search string byte size, search string (uppercase), unknown (0)


Folder Menu

r:m:s:t, sort?, folder id, unknown (0)

The first argument to every menu request is a four-byte number where each byte means something different. This byte is referred to as r:m:s:t in the Beat Link code because of the function of its component bytes (requester:menu:slot:type):

The first byte is always the device number D of the player making the request.

The second byte of the first argument identifies which menu location on the player will be used to display the result (for example, the screen is sometimes split with the user scrolling down the left, which is menu location 1, while displaying the contents of the selected item on the right, which is menu location 2, and the response format can be different in these cases). When showing metadata preview for a selected track, the menu “location” value is 3, and when loading non-text data like waveforms, album art or beat grids, the value of this byte is 8.

The third byte of this argument identifies the media slot, Sr, that information is being requested from. It has the same values used in CDJ status packets.

And the final byte identifies fhe media type, Tr being asked about, with values also as used in CDJ status packets.

As noted in the above table, there is a search “menu”. This is how the text-search feature of CDJs with touch-strips is implemented. By passing an uppercase string argument (in UTF-16 with a trailing 0000 character), preceded by its byte length, you can obtain a list of all matching database entries (tracks, albums, artists, etc.)

1. Use -1 for “all”.