library context actions can block UI when many tracks selected
Bug #1395022 reported by
Owen Williams
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Confirmed
|
Medium
|
Unassigned |
Bug Description
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.
Changed in mixxx: | |
importance: | High → Medium |
tags: | removed: concurrency |
To post a comment you must log in.
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. :-/