Mixxx always starts with Traditional key notation

I cannot confirm this bug on Fedora for the current master. The preference settings are preserved between restarts when switching the key notation.

Maybe the debug logs give some insights? Please also try this again with a fresh config file.

Regarding the green table cell: I thought we had this sorted earlier.
@geozubuntu Is every cell you select green or is it just the file location cell?

Hello Uwe Klotz (uklotzde)

It happens also in windows as I wrote. How possible is to have 2 bad config files in 2 different OS ?

But to be sure I deleted the config file (mixxx.cfg) and rerun the software to confirm that it continues to happen. In both Mint and win.

Then I removed database (it is very big library took a lot of time to rescan) just to see that it happens again and in fact it is worse. Now it shows the TRaditional notation even if the settings are set for Lancelot but even worse because now when I analyzed a track key isn't appear at all !!!! Not even in traditional notation. Only in the tracks that have the info in their metadata appear but in traditional.. In both operating systems. Mixxx detects and shows BPM (i didn't check if BPM is correct) but it doesn't add the key any more.In both OS.

Then I completely uninstalled, removed settings folder completely and reinstall from scratch the last 2.3.0-alpha-pre (build master r6710). Rescaned my whole library (a lot of time again) to see that it continues to have the worst case described. No new keys after analyze and the existing in Tradditional..

So there is definitely something wrong with the code.

I didn't noticed anything wrong within the errors log file.
I attach the errors log and the config file so you can check.

Oh and something good.. Now (build master 6711) I can see the selected tracks path.. problem solved.

Thanks for your time.

you can see the file paths now also in Linux Mint? Looks like it was the Mint os theme styling that cell..

The last build I installed from scratch and continues is build 6711 I wrote 6710 by mistake.. The correct is 6711 . You will see it in the log anyway..

Key analysis will be back soon: https://github.com/mixxxdj/mixxx/pull/2010

But the non-functional key analysis doesn't affect the display of keys that have already been analyzed.

You don't need to delete your whole settings directory for testing. Just rename or move it temporarily and restore it after testing. I cannot afford losing my whole library just for testing ;)

If you have stored the musical key information in the file's metadata you don't need to re-analyze those tracks when importing them into a fresh library for testing.

@ronso0
You are right.. I still can't read the path of selected track due to this color. But before 6706 it didn't hppened.. Why it happens now? :(

@uklotzde
I know about the library. In fact I preserved it.. I just wanted to see if it is relevant that's why I rescaned. ;)

Unfortunately it reads the existing keys but present them in Tradditional notation in every rerun. In both OS..

I don't have a VM so I have to reboot each time...

probably due to some QT changes, dunno..
is it just the file path or any selected cell?

@ronso0

It is only the path cell of each selected track as you can see in the screenshot I posted in my first post above #1 with name MixxxKey.png :)

And it also shows how I see the keys each time I run the program..

okay, I'll look into it.

btw, is the small cover art/spinny next to overview always empty?

@ronso0

If I load a track with artwork, it appears there. I just schecked it. If I load a track without artwork I can see only the large spinnie. But I can't see the small spinnie, it appears empty.. This in Linux Mint, I didn't check in windows. Must reboot to check in win.

@ronso0

There is something wrong there too.. With small spinnie selected, I load a track with artwork then I load another track without artwork but the previous artwork is not cleared and continues to appear. Then I load anothertrack with artwork and the 2 artworks "blend". The new artwork is rendered on top of the previous, it should first clean the previous artwork and then render the new. Only small spinnie has problem.

Ok, I am able to reproduce the bug when switching the key notation.

The behavior is really strange, sometimes it works, sometimes it doesn't. I really don't understand what the code tries to achieve and refuse to touch it. Everything is scattered with no clear initialization order and some statics in KeyUtils.

Mixxx 2.2.0 doesn't seem to be affected. Since I didn't notice any major code changes for this parts of the code between 2.2 and 2.3 I suppose the bug might be caused by a slight change in initialization order or a race condition.

fix for the spinnies is in https://github.com/mixxxdj/mixxx/pull/2013

I am still experiencing this issue (2.3.0-alpha-pre (build master r6745)).

@swiftb0y
It hasn't been fixed yet. It isn't marked in progress yet. That's why you are still experiencing it.

@ronso0
Has the pull which fixes the spinnies been included to any build master ?
I ask because in

2.3.0-alpha-pre (build master r6715) on Mint 19.1 Tessa (bionic)

the small spinnies continue not to work as expected on Tango skin.. Only the small spinnies.They don't appear at all and when load a track without cover art it shows the coverart of the previous track which had an artwork. This stays there until a new coverart is loaded no matter how many tracks without artworks have been loaded in between.

Here is a possible fix:
https://github.com/mixxxdj/mixxx/pull/2063

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