expressport leaves rekordbox's OneLibrary (exportLibrary.db, exportExt.pdb) on a stick whose library it replaces #208

What happened

On 2026-09-30, rekordbox 7 opened with a stick attached that had been exported by rekordbox and later written by baken expressport. It showed:

We have found a library inconsistency on the device you are using

It then pointed at "Playlists found only in Device Library" and "Playlists found only in OneLibrary", and offered to export the mismatched playlists.

Why

rekordbox 7 writes two libraries on a stick, side by side in PIONEER/rekordbox/:

• the Device Library: export.pdb and exportExt.pdb
• the OneLibrary: exportLibrary.db, with exportLibrary.db-wal and -shm next to it

expressport writes export.pdb and never touches the other files: nothing in crates/baken-export refers to exportLibrary.db or exportExt.pdb. So when it replaces the library on a stick rekordbox exported, the stick ends up carrying two libraries that disagree: our export.pdb, and rekordbox's older exportLibrary.db and exportExt.pdb.

What that breaks

• rekordbox flags the stick, as above. If the user accepts its offer, rekordbox writes its own playlists back onto the stick.
• OneLibrary players (CDJ-3000X, XDJ-AZ, OPUS-QUAD, OMNIS-DUO) read exportLibrary.db, so they show rekordbox's old library rather than the one just written. After --prune, its tracks can point at files that are gone.
• exportExt.pdb holds rekordbox's extension tables for the old Device Library. What a player makes of a stale one next to a new export.pdb is not known.
• The CDJ-3000: which library it reads when a stick carries both is not known. Player reports for baken expressport (out of beta since 4.3.0; CDJ-3000 and CDJ-2000NXS2 confirmed) #116's passes were all on sticks without a OneLibrary.

The README already says to give expressport a stick of its own. But nothing stops a run over a rekordbox stick, and the Mac app's USB Export (1.2.0, on TestFlight) asks "replace the library?" with a promise that the players will show only the chosen playlists, which is untrue here.

Proposal

1. plan detects it. If any of PIONEER/rekordbox/exportLibrary.db, exportLibrary.db-wal, exportLibrary.db-shm or exportExt.pdb exists on the device, report it before anything is written, the way the stick-format warnings are reported (expressport: warn before writing when the stick's filesystem or partition table rules out older players #184). --dry-run shows it too.
2. Replacing the library removes them. The run removes those files, so the stick carries one consistent library, and the report counts what was removed. A OneLibrary player then says OneLibrary not found, as on any expressport stick (expressport: OneLibrary players (CDJ-3000X, XDJ-AZ, OPUS-QUAD, OMNIS-DUO) #139), instead of showing a library that is no longer there.
3. Alternative to 2: refuse, unless a flag such as --remove-onelibrary is given. This is safer against surprise, but a stick someone already chose to write to cannot be used without it.

The Mac app would show 1 in its pre-flight, and would move its confirmation to state the removal before the export starts.

Checks

• An FSKit FAT image with a rekordbox-exported PIONEER/rekordbox/ (all five files), run expressport over it, and confirm the report and that the removal worked (scripts/fskit-check.py has the image setup).
• A sandboxed run (the Mac app), because files the app did not create are what it is least likely to be allowed to remove.
• On hardware, when someone has the time: a CDJ-3000 with a stick that carries both libraries, to learn which one it reads.

Related: #139 (writing OneLibrary, which would make the stale copy moot) and #116 (the players the Device Library was confirmed on).