Waveform glitch when adjusting loop_out (while playing)

[ronso0]

Bug Description

Occurs with all renderers AFAICT

The issue is not fully visible in the video. It's like the waveform is moving in the background with ~20% opacity and is overlayed with a second stuttering view.
https://github.com/mixxxdj/mixxx/assets/5934199/cdbe9f94-4bb6-48bb-a4c2-d4c549f3db01

Doesn't occur with 2.3.6

Version

No response

OS

No response

[JoergAtGithub]

Just tested this: Windows seems not to be affected.
Could you please add more information about you OS, Qt version and graphics driver.

[ronso0]

Linux (Ubuntu 20.04.5)
Qt 5.12.8
4.6 (Compatibility Profile) Mesa 21.2.6 (Mesa Intel(R) UHD Graphics 620 (KBL GT2))

I'm currently bisecting.

[ronso0]

It's 38a9391
If I go back one commit it's fine as before.

[ronso0]

Btw, this reminds me of extending the smoke test check list.

[ywwg]

This does seem like a release-blocking regression. It also seems like we can't really revert the bad commit because that is needed too.

[JoergAtGithub]

Have a look on #12522 which doesn't return the expected playpos. This might be related.

[JoergAtGithub]

Could you please list step by step, what I need to click to reproduce this.
My guess is, that VisualPlayPosition::set is called with inconsistent data. Printing the arguments of this function to the log might help to understand this.

[ronso0]

Just enable a loop, play it, then click and hold loop_out to drag the out marker along with the playpos.
Audio is fine but it seems the visual playpos jumps between loop_in and loop_out at a very high rate, therefore the two 'shadow' images.

[JoergAtGithub]

Here it looks like this:
https://github.com/mixxxdj/mixxx/assets/64457745/b8b49f69-4957-4b55-bcb7-ae9d9dec3315

[ywwg]

since this is only visual and does not affect audio output, we think this doesn't qualify as a blocker

[ronso0]

Well, it's very confusing, and it's a regression.
IMO that's severe enough to be fixed in 2.4 rather than wait for 2.4.1