Mixxx 2.3.0 - Recognizing Song data after file relocation

Every now and then I tend to re-structure my music collection file structure. In prior versions to 2.3.0 when I would move files and re-scan the library it would find the files in its new location keeping intact the Song rating, cues, etc…

Starting in 2.3.0 this is no longer the case, When I move file locations Mixxx seems to keep the Key/BPM data but it loses the Rating data and marks the file as missing so it gets removed from all of my playlists.

I am not sure if this has been mentioned but I wanted to because while this doesnt affect me much it could be an issue to someone else with bigger collections.


I cannot confirm this bug. Please elaborate.

I tested exactly the workflow you mentioned by moving tracks between different subfolders. Rescanning the library finds the files at the new location and then updates the location of existing tracks instead of adding them as new. Tracks in playlists and crates as well as all metadata are preserved.

We even have automated tests for this feature that should fail if relocating tracks is broken.

The answer is strange, because it is the exact reason I reverted to 2.2.4 (latest stable version).
I tried to have both 2.2.4 and 2.3.0 running together but this is impossible so far. Even changing the path in order to have 2.3.0 installed in another directory, it removes the previous installed version…
I confirm that when rescaning, it find the new location BUT keeps the oldest and, when you attempt to load it you get a missing message.
Cofiguration very simple, as test environment:

  • Windows 10
  • Fresh install
  • A single sound card
  • just using the PC speaker
    I therefore didn’t try going life using extra devices :slight_smile:

Please compare artist, title, and duration (in seconds) of the re-imported files. On any differences Mixxx won’t be able to detect them as duplicates.

Hi Tapir,

The file move isnt changing any track metadata. Literally it is “Move file from one folder to another and than re-scan library”.

Upon further review of this issue, it seems that some files are recognized and some files are not. I havent been able to figure out why though. I just moved about 300 files (under the same directory structure, just to a different folder) and after re-scan, about half of the files were marked as missing while the others were found and added back as valid tracks.

Upon further review, this is somehow metadata related. Even though I am in no way changing any metadata prior to moving the files.

I decided to use the import metadata Function (File Right click > Metadata > Import Metadata from file) for all files I was going to move prior to moving them. Once I did that, I moved the files and re-scanned thew library, all of the files were found and none were marked as missing.

The issue here is that I never had to do this before. Why would there be a discrepancy between the pre move metadata and post move metadata?


Do any of the files have missing Metadata? IIRC we changed the algorithm for deriving thr track title from the filename for these files. That could be related.

Just checked: Only filename and duration are considered for identifying moved tracks. Other metadata is not considered.

The difference in duration must be strictly less than 1 second. Tracks are added to the library with the duration read from the metadata. The metadata might be adjusted with the actual duration of the audio stream when decoding the file for the first time. The duration encoded in the metadata is often imprecise. Unfortunately the actual duration could also vary slightly depending on the decoder that is used.

Which file types are affected?

Please check if the duration of an affected track changes when reimporting metadata and again afterwards when loading the track onto a deck.

If the filename is considered, does that mean we don’t detect renamed files?

This simple detection of moved tracks has not changed. Renamed files will be imported as new tracks if no missing track with the same file name exists.

following this topic with great interest.

Renamed and moved files is one of the crucial reasons that I use traktor; I don’t have a single playlist there, only OS folders. This is implemented there using an unique fingerprint called AUDIO_ID.

I confirmed that Rekordox v6 supports renamed files as well; I don’t know which fingerprint it uses.

AFAIK we already have chromaprint support for looking up songs from Musicbrainz. Couldn’t we use that for detecting relocated songs?

One option would be to use the AcoustId/Chromaprint fingerprint that could be calculated locally. Currently we only calculate it on demand when looking up individual tracks on MusicBrainz. Only the first 30 seconds are used afaik.

Using MusicBrainz for this purpose doesn’t work, simply because the number of requests for a single API key is limited. It would also require manual resolution of ambiguous results whenever adding tracks to the Mixxx database.

Feel free to make a proposal on how duplicate track detection should work.