prioritize analysis of tracks loaded for 1st time over running (re)analysis i.e. samplers

[mixxxbot]

Reported by: ronso0
Date: 2018-10-28T17:26:58Z
Status: Confirmed
Importance: Low
Launchpad Issue: lp1800369

---

• start Mixxx

• load some samplers

• Preferences > Normalization > Analysis
    check [x] re-analyze and overwrite an existing value

• restart Mixxx

• load a yet unplayed track into a deck
  = deck is not analyzed as long as samplers are still re-analyzed

while the decks can actually be played it would much better to have the overview waveforms available as soon as possible.

Side effect:
with more samplers loaded than the current skin can display, there occurs a 'mysterious delay' between the last visible sampler and the last loaded deck being analyzed...

2.2.0-beta (build 2.2__2018-10-28 r6597)

[mixxxbot]

Commented by: ronso0
Date: 2018-10-28T23:10:00Z

---

this gave me some headaches, especially when I presented Mixxx during our open-decks sessions. usually, if waveforms were missing it was mostly an indicator my sound devices were unconfigured/broken.

[mixxxbot]

Commented by: daschuer
Date: 2018-10-30T15:41:03Z

---

We have an overlay text on the waveform overwiew. Should we add something to the scrolling waveform as well?

I am unsure about piorizing the deck over the samplers. It is always the one the user is waiting for that should have priority. Can we predict it?
We may also consider to revert the deck priority so that a last added is scheduled first. This way the user can always control what hapoens. I think this will have also solved your issue. Right? What do you think?

[mixxxbot]

Commented by: ronso0
Date: 2018-10-30T18:11:00Z

---

In the case I described the overlay text is just irritating ("what's happening in the background? Why that delay?") because the reason for delay is not obvious, even less with hidden samplers.

So Yes, adding the last loaded deck/sampler at top of the analyzer queue would help a lot I think.

[mixxxbot]

Commented by: uklotzde
Date: 2018-10-30T22:14:39Z

---

Please consider postponing any code changes until #1624 has been merged. I'm not willing to resolve more merge conflicts after I completed working on the multi-threaded analysis long ago.

I still need to resolve build issues of after rebasing this PR on master recently.

[mixxxbot]

Commented by: daschuer
Date: 2018-10-31T06:34:37Z

---

Oh yes. I think a fix should be merged together with your changes.
do you like the proposed change here?

Sorry for the delay reviewing this.

[mixxxbot]

Commented by: uklotzde
Date: 2018-12-23T11:53:13Z

---

PlayerManager uses a single analysis queue/scheduler for regular, preview, and sampler decks. This might be split into separate queues/schedulers that are suspended and resumed internally according to some prioritization strategy.

Currently (as of #1624) only the batch analysis is suspended while any ad-hoc analysis in PlayerManager is running. The ad-hoc analysis utilizes half of the CPU cores used by batch analysis to avoid hiccups while performing live. Batch analysis is supposed to be executed during preparation and therefore is allowed to use more cores for maximum performance.

[mixxxbot]

Commented by: ronso0
Date: 2019-11-26T14:51:52Z

---

I just set it to LOW instead of WISHLIST as it's not nice-to-have but seriously affects the GUI feedback as well as replay gain leveling of newly added tracks. See my first comment for more context.