WaveformRenderMark: Fix debug assertion for special case

[uklotzde]

The debug assertion triggered for samplePosition = sampleEndPosition = 0 (only the first occurrence actually but I fixed both).

[Holzhaus]

The debug assertion triggered for samplePosition = sampleEndPosition = 0 (only the first occurrence actually but I fixed both).

When does that happen?
For regular hotcues, sampleEndPosition should be -1. For loop cues, this could happen if and only if we allow zero-length loops. Do we?

[uklotzde]

The debug assertion triggered for samplePosition = sampleEndPosition = 0 (only the first occurrence actually but I fixed both).

When does that happen?
For regular hotcues, sampleEndPosition should be -1. For loop cues, this could happen if and only if we allow zero-length loops. Do we?

Happened when loading a track.

[uklotzde]

Maybe caused by parsing the Serato tags + custom file handling: Serato export enabled + parsing the file tags unconditionally when loading a track (i.e. updating the Track object with its cues from file tags after loading from the database).

[uklotzde]

I noticed another nasty and unintended side-effect: Reimporting the Serato tags resets the BPM of a track, even if it was locked.

[Holzhaus]

Maybe caused by parsing the Serato tags + custom file handling: Serato export enabled + parsing the file tags unconditionally when loading a track (i.e. updating the Track object with its cues from file tags after loading from the database).

You mean that the change signal fires and leads to a data race where the start position has the new state and the end position has the old state?

[uklotzde]

I don't know why it happens. But the issue is real.