SelectNextTrack & SelectPrevTrack cause the GUI to freeze for a few seconds

[Sean M. Pappalardo]

Using SelectNextTrack & SelectPrevTrack (like from a MIDI controller or the cursor up & down keys) in the Library cause the GUI to freeze for a few seconds (or on the order of minutes if you scroll very far) when you try to scroll down beyond the current page. I find that once you've scrolled a few pages, you can go back and forth within those pages relatively quickly, so it's like it's populating memory with something the first time you scroll. This "cache" is reset if you switch to another mode (Browse, Playlists.)

[Sean M. Pappalardo (pegasus-renegadetech)]

Here's a backtrace I got by trying to scroll very far with a MIDI controller then hitting CTRL-C. No songs were loaded.

[Sean M. Pappalardo (pegasus-renegadetech)]

I ran Mixxx, immediately proceeded to scroll to the end of my 550-file library, and told it to close when it was finished. It did, since this isn't a complete freeze. Then I ran gprof. Results attached.

This suggests QBasicAtomicInt::deref() & QBasicAtomicInt::ref() children are the problem, which happen to be replete with WTrackTable* calls. Any ideas as to what to try next?

[Sean M. Pappalardo (pegasus-renegadetech)]

Well, I found a sort of workaround...it's not perfect but its markedly better: basically you have to break table sorting. Make SortFilterProxyModel::lessThan just return false. (line 29 in proxymodel.cpp) The GUI still freezes while scrolling but for fractions of a second now, so there's another problem somewhere else. I hope that library rewrite is ready for 1.8...

[Sean M. Pappalardo (pegasus-renegadetech)]

This is not an issue in Windows on a dual Opteron 270 system in the 1.7 branch anymore. (The 1.7.0~beta1 still exhibits this though on the same system.)
The behavior still exists with the current 1.7 branch on my 2.53GHz Celeron D (single-core) Linux system though. So that further suggests a race condition.

[Sean M. Pappalardo (pegasus-renegadetech)]

I was wrong. This is not an issue when the library is not sorted. But if you sort by any column, this issue shows up.

[Phillip Whelan (pwhelan)]

I can confirm that this is due to Library sorting. It looks like some really dismal performance with sorting.

Here is a backtrace from a screen freeze:

Thread 1 (Thread 0xb60f0930 (LWP 23733)):
#0 0xb6b2e4f5 in QMutex::lock () from /usr/share/qt4/lib/libQtCore.so.4
---Type <return> to continue, or q <return> to quit---
#1 0xb6b71a7d in ?? () from /usr/share/qt4/lib/libQtCore.so.4
#2 0xb6b72465 in QRegExp::operator= () from /usr/share/qt4/lib/libQtCore.so.4
#3 0xb6b72625 in QRegExp::QRegExp () from /usr/share/qt4/lib/libQtCore.so.4
#4 0xb6b78f1c in QString::indexOf () from /usr/share/qt4/lib/libQtCore.so.4
#5 0x0816a491 in SortFilterProxyModel::lessThan (this=0xa0e0b58,
    left=@0xbfe7492c, right=@0xbfe7491c) at src/proxymodel.cpp:34

[Sean M. Pappalardo (pegasus-renegadetech)]

Fixed in trunk awhile ago.

[Swiftb0y (swiftb0y)]

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