Library scrolling very slow with cover art column showing

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.

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.

Does not affect Fedora 34.

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

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.

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

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.

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

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

Is this bug still reproducible?

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?

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.

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.

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.

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

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.

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

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