For the case that master track is visible, with posy == -164 and height == 163, the next track, due to the master track gap equal to 5, is positioned at posy == 4, thus, when the master gap goes from -1 to 4, getFirstTrackBinary() fails to find the first track and throws its assert. So this bug occurs when the master gap spans from the negative to positive, it should occur in all cases where the 5 px high master gap is positioned at -1, -2, -3, and -4.
This can be replicated, see the failing setup of the testingFindFirstTrackBinary.lua file.
Fixed by replacing
if height + posy == 0 then fixForMasterTCPgap = true end
with
if height + posy + MFXlist.MASTER_GAP >= 0 then fixForMasterTCPgap = true end
in the preamble of getFirstTrackBinary().
For the case that master track is visible, with posy == -164 and height == 163, the next track, due to the master track gap equal to 5, is positioned at posy == 4, thus, when the master gap goes from -1 to 4, getFirstTrackBinary() fails to find the first track and throws its assert. So this bug occurs when the master gap spans from the negative to positive, it should occur in all cases where the 5 px high master gap is positioned at -1, -2, -3, and -4. This can be replicated, see the failing setup of the testingFindFirstTrackBinary.lua file.