Detected Key format mismatch with already present TKEY ID3 tag

[delta]

Mixxx 1.12 stores its detected track key information in its own database in "Camelot" notation (1A, 1B, etc), which is more useful for mixing. However, it also seems to just copy over existing ID3 TKEY fields, which use a different format (standard key names). It should convert those on import, because now you apparently end up with two different formats in your database.

I have not actually checked this in the source, but from what I can tell this is what happens.

[RJ Skerry-Ryan (rryan)]

Hi delta -- we take the key from the TKEY and try to parse it by auto-detecting what format it's in. We support Mixxx's Lancelot notation, OpenKey notation, and "Traditional" notation. Also, if you setup a custom notation then we will try to use the custom notation you provided to parse the TKEY key.

In the database we store keys in their parsed representation. If we can't figure out the key from the text in TKEY then we bail and store the key as text and it isn't usable for key syncing.

What was the value of TKEY you had that didn't parse correctly?

[delta (deltakurshiva)]

This is what I ended up with in my library. I now realize that the D#min type entries (which were the ones already present) might not actually be the correct format either, but if that's the case Mixxx should just ignore them and perform its own scan anyway.

[Daniel Schürmann (daschuer)]

The bug has been fixed.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7228