library context actions can block UI when many tracks selected

[mixxxbot]

Reported by: ywwg
Date: 2014-11-21T14:36:12Z
Status: Confirmed
Importance: Medium
Launchpad Issue: lp1395022
Tags: gui, library

---

I was doing a bunch of work and ended up with my database in a state where only a few covers had been found. So naturally I did a select-all and clicked "refresh covers." It worked, but mixxx went dark while the processing was happening. Can we put in code to pop up a progress window if > kXXX files are put in the queue to locate covers? (Actually we should do this for other IO intensive operations like refreshing metadata.

[mixxxbot]

Commented by: rryan
Date: 2014-11-21T14:54:31Z

---

This is a general problem -- try select all add to playlist or select all reload track metadata.

For covers in particular, all the work is done in a different thread. The problem is that queueing the tracks to a different thread involves deserializing a TIO from the database for every file you have highlighted.

We have some bugs for the various context menu items and some of them also have a component of making the actual work be done in a different thread -- but in the case of covers the UI hangs because it is in a loop loading every selected track from the database.

When we have a separate thread for library operations and a TrackReference concept that lets you refer uniquely to a track without deserializing it then this will be resolvable but it's not for now. :-/

[mixxxbot]

Commented by: ywwg
Date: 2014-11-21T15:24:33Z

---

OK, but when the program starts up and the upgrade procedure fires, we get a nice cancelable progress dialog. Would it be possible to reuse that box in this case?

[mixxxbot]

Commented by: rryan
Date: 2014-11-21T15:43:53Z

---

During the scan that's a custom SQL query to select all tracks without cover art. In this case the way the code works is you have to deserialize all the TrackPointers first to tell the background thread what to do -- so that's the issue here. We need a sort of lightweight TrackReference thing to truly be able to say "here's some work to do" to a background thread without doing a ton of heavyweight work.

[mixxxbot]

Commented by: ywwg
Date: 2014-11-21T17:39:14Z

---

ok. I actually don't think this is that high priority so I'll bump it down.

[mixxxbot]

Commented by: daschuer
Date: 2014-11-21T19:10:53Z

---

Is a duplicate or Bug #⁠842689 ?

We have already a rotting solution in our repros.
#73
I hope I or Nazar finds time to put in a mergeable state.

[mixxxbot]

Commented by: Be-ing
Date: 2017-11-11T15:26:02Z

---

IMO right clicking a track in a track table shouldn't touch the database at all. The "Add to Playlist" and "Add to Crate" entries in the right click context menu are ugly hacks around the lack of a good drag-and-drop GUI for sorting tracks into playlists and crates. This will be fixed by the library redesign.

[mixxxbot]

Commented by: uklotzde
Date: 2017-11-11T21:29:24Z

---

If you want to visualize the relations between tracks and related entities like crates and playlists you always need some database queries, independent of how the actual UI works. Asynchronous communication of the corresponding results from the database to the UI would require to adjust and redraw this UI accordingly at any time, not just when the selection changes.

But as a first step the playlist and crate related sub-menus should populated lazily (i.e. only after actually opened by the user) instead of immediately in WTrackTableView::contextMenuEvent()! This would make the context menu much more responsive, independent of how many tracks have been selected.

[mixxxbot]

Commented by: uklotzde
Date: 2017-11-11T21:30:19Z

---

Lazily populating the context sub-menu is also an open issue in this PR:
#1341