Library scrolling very slow with cover art column showing

[Daniel Schürmann]

In the current Mixxx
2.4.0~alpha~pre-0ubuntu1~master~git7574~bionic
I can no longer scroll continuously through the library.

During Entering a search phrase Mixxx gets stuck and the keystrokes are buffered and appears only after a few seconds.

This makes Mixxx unusable for using Live.

My setup uses a internal spinning HD for library and files connected via S-ATTA.

Mixxx 2.3-beta is not affected.

I did not notice it before, because on my development machine I have only a few tracks and a internal SSD.

[ronso0 (ronso0)]

Can you still verify with 2.4?
There was an issue with high CPU for covers of missing tracks in 2.3 recently that got fixed.

[Daniel Schürmann (daschuer)]

I have just updated my productive system to 2.4 (latest main), but I need to downgrade right away because of this issue. Really a 2.4 blocker for me. I am currently on Ubuntu Focal 20.04 LTS.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Does not affect Fedora 34.

[ronso0 (ronso0)]

@daschuer
What debouncing time is used? maybe it's set too low.

[Uwe Klotz (uklotzde-deactivatedaccount)]

I have increased the debounce timeout to 1 sec, because the default doesn't work for me. But even the default doesn't make Mixxx unusable.

[ronso0 (ronso0)]

@daschuer
Does hiding the cover column restore normal scroll experience?

[Daniel Schürmann (daschuer)]

The debounce time is at 287 ms.
Restore defaults does not change the value.
Is this correct?

I have just set it to 1000 ms, but the scrolling issue remains unchanged.
The it effect the seatch result only.

By the way, unusable is a too hard term literally. It just hampers me in my normal workflow in a way that I prefer to use 2.3.

Do you have an idea what make has happened that creates the delay?
Did you test with the library + files on the same spinning HDD?

After changing the debounce time to 1000 Ms I have noticed another issue with the debounce time itself:
* You type the first character
* Wait for the result
* When it appears you instantly continue to type
* This is exactly the time when the cover arts are loaded and the GUI stalls again preventing to finish the search phrase.

A workaround would be to wait the debounce time again before refreshing the cover arts.
This would give the use the chance to delay cover art loading until the search phrase is complete or until he waits intentionally for cover arts.

Maybe this is a workaround for the scrolling issue as well, before we have found the root cause.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Please also consider that the cover art hashes need to be re-calculated once after upgrading to 2.4.

[Daniel Schürmann (daschuer)]

Yes! The issue is "fixed" when disabling the cover-art column.

[Be (be.ing)]

Is this bug still reproducible?

[Foss-4 (foss-4)]

I think yes. Explanation was given by Uwe https://bugs.launchpad.net/mixxx/+bug/1905124/comments/8

This is a one time process. So should this bug be set to wontfix as mixxx is behaving as intended? Maybe a hint about this should be added to the release notes?

[Daniel Schürmann (daschuer)]

Yes, that is the mayor issue not to switch to 2.4 branch of my productive setup.
It is a regression to 2.3 which already has covers.

[Foss-4 (foss-4)]

From my understanding, re-population of hash database is a one time process after which scrolling performance is then restored. This is not uncommon in software development. Not sure I would call this a regression.

But clearly this needs to be communicated to users, so that they can make an informed decision. Maybe instead of only mentioning this change in changelog, a dialog could be displayed offering to rehash covers for entire library with options

- "Update Cover Information"
- "Not Now" (dialog will appear again on next launch)
- "Don't Update Cover Information" (no rehashing and dialog will not re-appear)

Maybe we can also come up with better text, this is just to share the idea.

[Foss-4 (foss-4)]

And re: scrolling performance - there is a critical macOS qt bug opened 2019 Jan with recent activity:

Bug: https://bugreports.qt.io/browse/QTBUG-73117
Patch: https://codereview.qt-project.org/c/qt/qtbase/+/373409

Really hope the qt team will be able to address this.

[Be (be.ing)]

We may consider backporting that Qt patch to our vcpkg builds.

[Daniel Schürmann (daschuer)]

The issue is a redundant cover lookup in the main thread after a cover has been discovered without a cover digest. It is a one time issue, but if you have many files in the database it happens many times during a performance.

[Daniel Schürmann (daschuer)]

https://github.com/mixxxdj/mixxx/pull/4904

[Swiftb0y (swiftb0y)]

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