Closed mixxxbot closed 2 years ago
Commented by: uklotzde Date: 2018-04-18T17:42:47Z
https://github.com/mixxxdj/mixxx/pull/1624
I'll keep this bug and not mark it as a duplicate, because this one actually describes one of the issues with the current analysis architecture. Unrelated to multi-threading.
Commented by: uklotzde Date: 2018-04-18T17:43:55Z
Sorry, Sebastien, that I didn't notice this earlier!
Commented by: uklotzde Date: 2018-04-23T07:34:19Z
This is not a duplicate, but a known issue! In fact the new issue recently reported by Sean is a duplicate of this issue:
Commented by: uklotzde Date: 2018-04-23T07:38:26Z
We don't need a separate worker thread. I already have an idea in my mind how such a reactive, event-loop-driven TrackActionScheduler can be implemented efficiently:
Some parts of the new TrackAnalysisScheduler might be reusable.
Commented by: uklotzde Date: 2018-09-29T14:43:32Z
Unassigning myself, because I don't plan any major changes on the current software design of the UI. Even the mentioned reactive and multi-threaded redesign of the analysis has not been merged, yet.
Instead we should think about decoupling the backend from the frontend and eventually replace the frontend with QML components.
Commented by: uklotzde Date: 2020-04-21T07:32:33Z
Proof of concept using a modal progress dialog that can be aborted:
Commented by: uklotzde Date: 2021-02-24T18:05:59Z
The workaround is in place. Further improvements would require substantial changes to the architecture.
Issue closed with status Fix Released.
Reported by: sblaisot Date: 2016-02-20T17:11:24Z Status: Fix Released Importance: High Launchpad Issue: lp1547916 Tags: gui, library, metadata
I just discovered a bug in Mixxx 2.0.0 (64 bits on win 10 64b).
If you select a (rather) large number of tracks in the library, open right-click menu and select BPM->Reset tempo and beatgrid, the interface freezes until mixxx has finish resetting tempo and beatgrid on all these tracks.
I've just seen that with 1000 tracks selected.
This should probably be done in another low-priority thread.