Duplicate volta causes later repeats to play wrong

score needed

OK, confirmed. I'm at a loss though to explain why that is.

I unrolled the score and it unrolls correctly but plays wrong.

Please try the attached score, in which I believe this fixed.

The root cause seems to be that you have an additional 0-length 2nd volta in m17. I've removed that and playback now works.

I'm leaving this report open for a little longer to later be able to use my debugbuild and see if the interpretation logic can better handle such a situation without tripping up.
So far I haven't tested whether the cause is having a superimposed volta (which could happen by accident) or that it is 0-length.

The workaround is to delete the unnecessary volta.

I have a similar problem. The first volta (measures 20 and 21) in the attached file repeats correctly on playback but the second volta (measures 37 and 38) plays both measure 37 and 38 on the second time through. I couldn't find a problem with the volta. Help.

This seems to point that the root cause indeed is the duplication of volta elements, as when removing the technically duplicates on the 2nd-4th instruments, playback is restored.

So definitely a bug in the interpretation of what is currently allowing volta's to be added multiple times.
My only side thought here is that a volta should be a system element, and as such only be allowed to be added once. Then, just for with system text, we should have a mechanism to allow the display of it to be shown on multiple staves within a score, whilst still being just one real element.

I removed the voltas from the 2nd-4th staves and it plays correctly. I then entered them again using ctrl+click the volta in the palette. This should have fixed the replay problem but it went back playing volta 1 & 2 on the last repeat. I'm stumped. Perhaps @jeetee can look at this and provide some guidance. He may as for a new bug report but I'll let him decide that.

Thanks for sorting the workaround folks!

minimal example to be used for testing purposes

single staff version

You're right. I mis-tested apparently

Just some developer trace notes for my own benefit.

The duplicate volta causes the "collect"-logic to no longer see the following voltas, they're basically ignored. I think this is because the duplicate volta leads to the logic assuming there are overlapping voltas; a case currently not covered by the logic, which I would've expected to lead to ignoring the current overlap (= the duplicate) but apparently doesn't clean the local tracing stack fully, resulting in volta detection lockup.

Expecting to solve this cleanly within the coming week.

https://github.com/musescore/MuseScore/pull/6810 patches this by assuming that voltas starting on the same measure are likely duplicates and as such ignore all of those but the first parsed volta for that measure.

How about ignoring all but the longest? That might sort those odd cases or an( invisible) zero length volta?

I'm still dabbling a bit further to see whether we can change the patch from above into a more sturdy model

PR updated with a more proper fix on handling multiple overlapping volta cases; not just duplicates

Fixed in branch 3.x, commit 6b43ac8935

Fix #311986: handle duplicate voltas (repeat58)
Also handles overlapping voltas by splitting them into non-overlapping voltas with cross-section repeatlists (test will follow)

Fixed in branch 3.x, commit 6c374fd13b

_Merge pull request #6810 from jeetee/311986-handle-duplicate-voltas

[MU3] Fix #311986: handle duplicate voltas_

Fixed in branch master, commit ef4f173842

Fix #311986: handle duplicate voltas (repeat58)
Fixed initial voltas having the same start crash
Also handles overlapping voltas by splitting them into non-overlapping voltas with cross-section repeatlists

Automatically closed -- issue fixed for 2 weeks with no activity.