corruption when saving score containing a system beginning with a start repeat on an mmrest

• Sep 15, 2014 - 22:19
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

Ubuntu Studio 14.04, GIT commit: 3338af9

1) new score, 32 measure
2) add line break after bar 4
3) add start repeat to measure 5 (first measure of second system)
4) "M" to enable mmrests (you should have a 4-bar rest on first system, 28-bar rest on second system
5) save
6) reload

Result: a bad-looking 28-bar rest on second system (it appears to be drawn twice):

repeat-mmrest.png

Bad things then follow if you try editing, including crashes if linked parts are involved (eg, try adding a linked staff at this point).

Attachment Size
repeat-mmrest.png 10.9 KB

Comments

• Sep 15, 2014 - 23:36

BTW, the notice how the first start repeat in the screenshot above collides with the clef? This much was true even before the save/reload step. That is, any system that begins with a start repeat in an mmrest, the start repeat collides with the clef (or key signature, or time signature). There is code in computeMinWidth() that is supposed to add 0.5sp padding to the left of the start repeat, but it isn't getting hit. The corresponding code in layouX() *does* get hit, though. So I'm not sure yet what's up. But I'm betting the poor layout is actually just the first symptom of the underlying the problem that causes the really bad results on reload.

Reply

• Sep 24, 2014 - 15:47

If you save the resulting score and look at the file, you'll see the "real" measure 5 is written *before* the mmrest measure 5. If I reverse this in the file, it loads correctly. Maybe that's the order we should be writing them in? But it isn't just start repeats where this happens, so maybe that's intentional. It's only start repeats where it seems to cause problems, though.

Reply

• Oct 10, 2014 - 12:50

I'm affraid this fix broke one of my scores, in that one of the parts (which uses multi measure rests) now looks corrupted (score sent to Werner via email).
Not 100% sure though that it was this commit, but the culprit got to be between 7ab8acd and 9b8c7c6 and this here (853dbf4fd) is the most likely candidate.

Also Travis fails on it, in tst_parts

Reply

• Oct 10, 2014 - 15:48

Looks like the fixes were in read and layout only - does that means scores created previously are not corrupt and should be expected to load correctly now? Any gotchas I should be aware of?

Reply

• Oct 10, 2014 - 16:30

I loaded the score I had created a few weeks ago that discovered the problem, and so far, it *looks* good now. Are you finding the same, or are you finding older scores *still* look corrupt?

I had found I could remove the problem by switching mmrests, saving, reloading, then turning mmrests on. But if I saved and reloaded again, the problem returned. If you try that, does the problem stay gone?

Reply