Library scrolling very slow with cover art column showing

[mixxxbot]

Reported by: daschuer
Date: 2020-11-21T11:37:48Z
Status: In Progress
Importance: High
Launchpad Issue: lp1905124
Tags: library, performance

---

In the current Mixxx
2.4.0alphapre-0ubuntu1mastergit7574~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.

[mixxxbot]

Commented by: ronso0
Date: 2021-05-11T12:24:59Z

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2021-10-22T14:24:38Z

---

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.

[mixxxbot]

Commented by: uklotzde
Date: 2021-10-22T21:01:13Z

---

Does not affect Fedora 34.

[mixxxbot]

Commented by: ronso0
Date: 2021-10-22T21:42:00Z

---

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

[mixxxbot]

Commented by: uklotzde
Date: 2021-10-22T22:06:29Z

---

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.

[mixxxbot]

Commented by: ronso0
Date: 2021-10-22T23:31:36Z

---

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

[mixxxbot]

Commented by: daschuer
Date: 2021-10-22T23:41:56Z

---

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.

[mixxxbot]

Commented by: uklotzde
Date: 2021-10-23T11:10:43Z

---

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

[mixxxbot]

Commented by: daschuer
Date: 2021-10-25T16:00:28Z

---

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

[mixxxbot]

Commented by: Be-ing
Date: 2021-11-13T23:38:49Z

---

Is this bug still reproducible?

[mixxxbot]

Commented by: foss-4
Date: 2021-11-14T10:39:52Z

---

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?

[mixxxbot]

Commented by: daschuer
Date: 2021-11-14T13:08:26Z

---

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.

[mixxxbot]

Commented by: foss-4
Date: 2021-11-14T13:26:40Z

---

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.

[mixxxbot]

Commented by: foss-4
Date: 2021-11-14T13:41:40Z

---

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.

[mixxxbot]

Commented by: Be-ing
Date: 2021-11-14T13:51:51Z

---

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

[mixxxbot]

Commented by: daschuer
Date: 2022-08-20T10:49:31Z

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2022-08-20T11:12:25Z

---

#4904

[ronso0]

fixed by #4904