[jwilkins]

Q-01 in the feature research doc: view and edit the players' and the mixer's My Settings in Booth, take the ones a player saved onto a stick, put a chosen set on any stick, and never write over a player's saved settings unless asked (PP-32).

What changed

The four files, as bytes. booth-cli's new export::settings handles MYSETTING.DAT, MYSETTING2.DAT, DJMMYSETTING.DAT and DEVSETTING.DAT. Each file is a header, one byte per setting, and a CRC16-XMODEM checksum. Booth knows 46 settings and changes only their bytes, recomputing the checksum. Every other byte of a file is kept exactly as it was.

My Settings sheet. A My Settings button sits beside Settings in the dock. It opens all 46 settings, grouped the way rekordbox's preferences group them, each with a menu of its values; hovering shows rekordbox's own value. It also has:

• Take a drive's, plus a one-click "Take USB's" for the stick on the dock. These take the settings a player saved there with SAVE, or that rekordbox wrote, one file at a time. A file that doesn't read is left out and named, and the other files are still taken.
• rekordbox's (start from the defaults) and None (stop putting settings on drives).
• The collection has no set until somebody makes one.

On sync, only where the drive has none of its own.

• Each drive's record now says which settings files Booth put on it and what they were. When the set is edited, Booth replaces its own files and nothing else.
• If a player has since saved over one of those files, it no longer matches the record, and it counts as the drive's own again.
• The sync sheet has a Settings line saying what happens to each file: goes on, already on, replaces Booth's, or the drive's own is kept.
• When the drive has its own, Put mine over the drive's own replaces them for the one write it is ticked for.
• The dock's delta says "settings" when some are waiting.

booth-cli settings <drive>. Prints what a drive's settings files set, setting by setting, with rekordbox's value beside each one that differs. It also names any byte that differs where no setting is known. That is how a file a CDJ-3000 saved can be looked at.

Why it's right

What each byte means was measured, not taken on trust. The map comes from rekordcrate (MPL-2.0). rekordcrate keeps 74 files from rekordbox 6.6.1, each with one setting changed. Every one of them differs from rekordbox's default file in exactly one body byte, plus the checksum. That byte and its value are rekordcrate's in all 74.

pyrekordbox's documentation disagrees in two places, and the files side with rekordcrate:

Setting	pyrekordbox says	The files say
Hot cue auto load's "rekordbox setting"	0x83	0x82
Languages	numbered from 0x80	numbered from 0x81

All 82 of rekordcrate's settings files check out with the checksum rule: CRC16-XMODEM over the body, or over everything before the checksum in the mixer's file.

The defaults are rekordbox's bytes, not rekordcrate's. rekordbox writes the header version as 0.001 in both player files and 1.000 in the mixer's. rekordcrate's default constructors write 6.6.1 in all four. Booth starts from rekordbox's own empty-export files, byte for byte, and a test holds them.

Checked by a reader that shares no code with the writer. The tests write every value of every setting and read the file back with rekordcrate. Each one comes back byte for byte when rekordcrate writes it out again, and it changes only the setting rekordcrate names the same way. An ignored test reads the 74 fixtures, in the same style as the audit's.

Whose a file is depends on what Booth put there, not on the header. PP-32's note suggested going by a non-rekordbox header. Nobody here has seen the header a player writes when it saves, so a rule built on it would be a guess. A byte-for-byte match against Booth's own last write is a fact.

Decided before writing, as the rest of the sync is. The plan works from the drive's record alone, so it stays a function a test can build. The sheet and the write read the stick itself, which is the only thing that knows whether a player has saved since. The export writes whatever files it is given and reads each one back.

The record changes when the write reports back, not before. I found this by reading my own diff. If the record were written first, a failed write would leave Booth's old file on the stick under a record naming the new one. The next sync would then keep the old file as the drive's own, forever.

The other ways, and why they lost

• Use rekordcrate's typed structs to read and write. rekordcrate refuses a file with any unexpected byte where no setting has been named. A file a player saved, or a newer rekordbox wrote, is exactly where an unnamed setting would show up. Writing back from fields would also drop such a byte. So rekordcrate stays a dev-dependency, as the independent reader.
• Write settings only to a stick that has none, full stop. Then a set Booth wrote last month could never be updated. Every edit would need the explicit "over" each time, and the explicit write-over would stop meaning "this is somebody else's".
• Start every collection with rekordbox's defaults and write them everywhere. That is rekordbox's behaviour. But a stick that suddenly carries settings changes a player when they're loaded, and a DJ who never asked would find Quantize back on. No set until somebody makes one.
• Keep the set in Booth's own config, not the collection. The collection is what is backed up with the drives' records, and the drive record has to agree with the set it was written from.

Worth a second opinion

• No player has loaded a set Booth wrote. Everything above is checked against rekordbox's files and rekordcrate, not against a CDJ. One LOAD on a CDJ-3000 from a stick this writes would settle it. Running booth-cli settings on a stick a CDJ-3000 has saved to would also show whether it writes bytes nobody has named.
• "Already exactly ours" is recorded as Booth's. If a stick's file matches Booth's set byte for byte, the record calls it Booth's, so a later edit replaces it. That holds even if a player or rekordbox wrote it. The content was identical to the DJ's own set, so I judged nothing is lost. But it does make one exception to "the drive's own stays".
• An unreadable settings file is kept, not written over. A read error that isn't "not found" counts as the drive's own. The reasoning is that a write over it would most likely fail as the read did. That is reasoned, not tried.
• A file with a bad checksum on the stick also counts as the drive's own. Import refuses it, but sync won't replace it unless asked. That is conservative, and arguably a damaged file is one Booth should offer to replace.
• Drives written before this have no record, so the dock says "settings" for them until their next write. The sheet, which reads the stick, then shows the real answer: kept, where rekordbox put files there.
• The website's "what works today" list is untouched. I'd add this at the next release, as with 0.1.1.

Gates pass: cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, and env -u BOOTH_WHISPER_MODEL -u BOOTH_WHISPER_BIN -u BOOTH_GENRE_MODEL cargo test --workspace (31 test binaries, including the new my_settings). The ignored fixture test passes against rekordcrate's 74 files.

---

Generated by Claude Code