GUI freeze trying to add ~100 songs to playlist/crate

[Max Linke]

using r 3250 the GUI freezes for some time if you add ~100 and more songs to a playlist or crate when mixxx was just started.
So until all songs are added to the playlist/crate the GUI is frozen and non responsive this and it takes several seconds (up to minutes) until mixxx respoinds again. A similar behaviour can be observed emptying a large auto-Dj queue.

If the songs have already been added to a playlist/crate while mixxx is running everything is fine and i just experiance a freeze of about 0.5 sec.

I think this could be a problem if you want to add a large playlist to Auto-DJ at the beginning of the set or delete a old queue.
For someone new to mixxx this could look like it's crashed although it's actually running fine

Here are some debug messages I repeatedly get during a GUI freeze

Debug [Main]: TrackDAO(0x1d25810) addTracks took 2 ms to add 0 tracks
Debug [Main]: CrateFeature::dropAcceptChild adding track 54 to crate 1
Debug [Main]: Location "/home/kain88/testMusic2/Xandria/India/11 Winterhearted.mp3" is already in the DB
Debug [Main]: Committing transaction on "qt_sql_default_connection" result: true

Debug [Main]: Committing transaction on "qt_sql_default_connection" result: true
Debug [Main]: BeatFactory::loadBeatsFromByteArray could not parse serialized beats.

Debug [Main]: Committing transaction on "qt_sql_default_connection" result: true
Debug [Main]: TrackDAO(0xfbb7e0) addTracks took 1 ms to add 0 tracks
Debug [Main]: Committing transaction on "qt_sql_default_connection" result: true
Debug [Main]: Location "/home/kain88/testMusic/Xandria/India/10 Dancer.mp3" is already in the DB

[Daniel Schürmann (daschuer)]

Hi Max,

I think you hit a problem, caused by the way the database is handled in Mixxx. It is itching on all edges where we have long database transactions. I think if you search for bugs, you will find many similar ones.

This problem is partly solved by doing some long transactions like collecting songs from Rhythmbox xml file in a separate thread.

But I would prefer to adapt the common solution from many mediaplayers like Banshee and Clementine to move all database transaction in an own dedicated GUI thread.

This was one reason for starting my Reuse Clementine code Project. I think it will be best to copy there ideas how to handle a database, but it will have been a deep impact to Mixxx.

Kind reagrds,

Daniel

[Max Linke (max-linke)]

Hi

I think we could speed this thing up without a rewrite of the library code. It seems that we open and close a SqlQuery for every track that is added into the playlist/crate. This should be faster if we do with just one query, similar to your patch for the library-scanner, https://bugs.launchpad.net/mixxx/+bug/801700.

best Max

[Max Linke (max-linke)]

http://www.sqlite.org/faq.html#q19

I think this answers why our GUI freezes. From the output it is clear that we have commit a lot of transactions, which are expensive according to sql docs. So doing all the adding to playlist in one transaction really should speed things up

[Max Linke (max-linke)]

This patch should fix some of it.

Songs are now added to autoDj in just one transaction and songs are also removed from
crates/playlists with one transaction. Speeds things up quite a lot.

[Max Linke (max-linke)]

This new version also reduces the time until the context menu is shown when a lot of tracks are selected.

[Max Linke (max-linke)]

This version also fixes the freeze for drag'n'drop events.

[RJ Skerry-Ryan (rryan)]

Thanks Max -- the patch looks good to me except I would prefer that you qSort the input to removeTracksFromPlaylist instead of relying on the caller to provide them in descending order.

[Max Linke (max-linke)]

I've moved the ordering to the playlistdao and found a method that should do the
reversing a bit faster.

[Swiftb0y (swiftb0y)]

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