Mixxx

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

Bug #361170 reported by Sean M. Pappalardo on 2009-04-14

Affects		Status	Importance	Assigned to	Milestone
	Mixxx	Fix Released	Medium	Albert Santoni	Mixxx 1.8.0
	1.7	Won't Fix	Undecided	Unassigned

Bug Description

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.)

See original description

Tags:

Revision history for this message

Sean M. Pappalardo (pegasus-renegadetech) wrote on 2009-04-14:

Forced backtrace Edit (17.2 KiB, text/plain)

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

Changed in mixxx:
importance:	Undecided → Medium
status:	New → Confirmed

Revision history for this message

Sean M. Pappalardo (pegasus-renegadetech) wrote on 2009-04-15:

gprof analysis Edit (83.8 KiB, application/octet-stream)

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?

description:

updated

Revision history for this message

Sean M. Pappalardo (pegasus-renegadetech) wrote on 2009-04-15:

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...

Revision history for this message

Sean M. Pappalardo (pegasus-renegadetech) wrote on 2009-05-03:

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.

Revision history for this message

Sean M. Pappalardo (pegasus-renegadetech) wrote on 2009-07-16:

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.

tags:

added: library

Revision history for this message

Phillip Whelan (pwhelan) wrote on 2009-07-16:

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