Rekordbox USB cache fails to clear after removal, causing device recognition failure and UI content mixing

[eXWoLL]

Bug Description

At a gig with multiple DJs, I experienced a severe issue with Mixxx's Rekordbox USB handling. After one DJ removed their USB, the system failed to clear the cache. Mixxx continued to show the removed USB as present. When attempting to refresh via the blue text line in the main window, nothing happened. Subsequently, the contents of two different USBs became intermixed—tracks from one drive were displayed under the other drive's listing. No songs could be loaded from either drive.

Expected behavior

• When a USB drive is removed, Mixxx should clear it from the sidebar and release its resources.
• The "Refresh" action should rescandevice mount points and update the library view.
• Different USB drives should maintain separate and distinct library listings.

Actual behavior

• Removed USB remained visible and selectable.

• Refresh action had no effect.

• Contents of two different USBs were shown intermixed (e.g., USB A showed tracks from USB B).

• Tracks were unloadable from either drive.

• The sticks were connected via a USB3.2 hub (non-powered), but when another port was tried, the issues remained.

• Issue was fixed via restarting the program.

• The usb's had multiple playlists (GBs worth of tracks)

IMO some additional way of flushing or restarting the USB cache should be made available to avoid these issues.
ps. will attach log later

Version

2.6

OS

Windows 11

[eXWoLL]

Log from when the issue appeared
Log after the restart

Issue started in mixxxlog2 file:

1. The first DJ inserted their USB (rekordbox) and was playing normally;
2. the second DJ inserted their USB sometime later for a B2B session, but their drive wasn't being recognized by mixxx, the drive letter wasn't appearing (windows recognized it without issues).
3. Several tries to "refresh" the list via the blue line (should be a button TBH a line is kinda hard to figure, especially with that small text) with no luck. The drive was the same model that the first DJ was using.
4. Then it was decided to try another USB, but the result was the same.
5. The second drive was then removed.
6. The DJ1 then tried to play their own songs, but found out that the drive was showing his folders, but the songs were a random mix with songs from DJ2; and none of them were loading
7. It was decided to restart the software.

Events after restart are in the mixxxlog1 file:

1. We decided to try again DJ2's USB2, thinking that maybe the software was having issues recognizing two drives of the same brand, but we had no luck
2. decided to just directly copy the contents of the USB to the computer and just use them from there; but Mixxx's lack of recursive searching within the "computer" submenu made that hope disappear (please fix Recursive searching in the file directory #11173 (comment))
3. We tried refreshing the rekordbox section again for the last time, and it worked.
4. Tried the USB1 but we had no luck, so just continued with USB2.

Including ai parsing results:

Time	Log	Who	Event	Result
22:54	log2	DJ1	Clicks Rekordbox section header	Table dropped & recreated
22:54	log2	DJ1	Navigates to E: node in tree	✅ parseDeviceDB fires → 92 tracks found
~22:54–00:23	log2	DJ1	Playing normally from E:	✅ Session running fine
00:23	log2	DJ2	Inserts USB (Windows assigns it F:)	Windows sees it fine
00:23	log2	DJ2	Navigates to E: in Rekordbox tree	doParseDeviceDB: false — already cached, no rescan
00:23:55–00:24:10	log2	DJ2	6× refresh clicks trying to get drive to appear	Table wiped 6 times, no parseDeviceDB fires
00:24:11	log2	DJ2	Navigates to F: node in tree	✅ parseDeviceDB fires → 56 tracks found
00:24:22	log2	DJ2	Browses F:/vibe playlist	✅ Working
00:27:11–00:29:43	log2	?	11× refresh clicks — USB2's second drive attempt	Table wiped repeatedly, no scan, drive never appears
00:29:49	log2	DJ2	Falls back to browsing F:/zapateu	Gives up on second USB
00:31:17–00:31:24	log2	?	6× more refresh clicks	No scan fires
00:31:58–00:32:03	log2	Both	Both E: and F: browsed simultaneously	Tracks from both drives merge into shared DB
00:33:50–00:34:03	log2	?	5× refresh clicks — DJ2's second drive, last attempt	Table dropped & recreated 5 times, no scan
00:34:43	log2	?	Navigates properly to F: node	✅ parseDeviceDB fires → 56 tracks found again
00:35:08+	log2	DJ1	Tries to load tracks from E: (DJ2's folder paths showing)	❌ Ghost tracks from removed drive — all fail to load
00:35:30–00:36:39	log2	DJ1	Dozens of TrackRecord failures on E:\azucar vip\*	❌ DJ2's tracks mapped to DJ1's drive letter
00:36:39	log2	DJ1	Tries to play R3ckzet - Vou Banindo	❌ "File could not be found" — hard load failure
00:36:50–00:37:34	log2	DJ1	7× refresh clicks in frustration	Table wiped 4 times (only the 4th triggers a drop)
00:37:14	log2	DJ1	Tries to play DoubKore - Lsd Stories	❌ "File could not be found"
00:37:29–00:38:06	log2	Both	6× more refresh clicks	Chaos
00:38:09	log2	?	Navigates to F: node properly	✅ parseDeviceDB → 56 tracks found — DJ2 back up
00:38:12	log2	DJ1	Tries Droplex - The Shadow	❌ Still failing on E:
00:38:33	log2	DJ1	Tries Avrosse - Statement	❌ Fails on both Channel1 and PreviewDeck1
00:39:16	log2	—	Mixxx restarted	Tables dropped cleanly on shutdown
00:39:19	log1	—	Mixxx starts fresh	Tables recreated clean
00:39:31	log1	—	Rekordbox section opened	Table drop + recreate
00:39:35	log1	DJ2	Navigates to F:	✅ 56 tracks found immediately
00:40:34–00:40:40	log1	DJ2	2× refresh — trying second USB again	No scan, drive never appears
00:43:53–00:44:01	log1	DJ2	3× more refresh — still trying second USB	No scan, gives up
00:46:30–00:46:32	log1	DJ1	2× refresh then navigates to E:	✅ parseDeviceDB → 551 tracks found
~00:46–02:00	log1	DJ1+DJ2	B2B session running normally from E: and F:	✅

Issue 1 — RekordboxFeature::activate() destroys the table without scanning [BUG]

Clicking the Rekordbox section header drops and recreates all three Rekordbox tables but only triggers a parseDeviceDB scan if the user then explicitly clicks on a drive node in the tree. If the drive node doesn't appear for whatever reason, the user re-triggers the header multiple times in succession, which wipe the table repeatedly with zero scan fired each time. In this session it happened multiple times across both logs with no scan.

The header click and the drive scan are two disconnected actions that look like one to the user.

Issue 2 — No "scanning" / busy state on the Rekordbox section [UX]

There is no visual feedback to distinguish between "no drive detected" and "drive detected but not yet scanned / scan in progress." Both states look identical (empty panel), so users reasonably keep clicking refresh. A loading indicator or per-drive status label would have prevented the entire refresh loop.

Issue 3 — Newly inserted drives are not auto-scanned [UX/FEATURE]

Mixxx uses lazy loading — a drive only gets scanned when the user navigates to its specific node in the sidebar tree. There is no automatic detection of newly plugged USB drives. Users expect the refresh button to do this. In a live B2B scenario where time pressure is high, the requirement to know to click a specific sub-node is not discoverable.

Issue 4 — Shared Rekordbox DB table causes track contamination across drives [BUG]

When two Rekordbox drives are browsed in the same session and one is then removed, tracks from the removed drive remain referenced in the internal SQLite library under their original drive letter paths. When the other DJ then browses their own drive (which Windows had previously also assigned that same letter), the ghost tracks appear in their folder view but point to files that no longer exist, causing cascading load failures. A restart is required to clear the state.

Issue 5 — Computer browser has no recursive search [BUG / known: #11173]

The file browser under "Computer" only lists audio files in the exact folder currently selected — no subdirectory traversal. Navigating through multiple folders (especially in the Rekordbox "Content" folder where each track is nested in its own directory) becomes impractical. This is a live-gig blocker when music isn't at the root level of a drive. Tracked in #11173.

Btw, still think that the UI is confusing for people coming from rekordbox, and is hard AF for them to find their tracks, since the rekordbox menu is all the way to the bottom, and thats a lot of distance to scroll through when there were other people playing with songs from the playlists, or crates.

The section needs some love to make the process more streamlined and ergonomic/intuitive for an external (non-owner) user that isnt familiar with the quirks of a system. Already mentioned some here

I don't know how much longer i'll be able to keep forcing my talent to play on mixxx to gather data in a live environment; so please implement these soon; otherwise I'll be forced to just go back to rekordbox for my gig's survival, and the testing environment will be closed for good.

[eXWoLL]

Dont know if I should create separate posts for each thing here, since they all share the same logs.

Edit: yeah decided to create the separate issues and link here to the logs.