**Reoccurring Problem**: Cannot Open Scores!! Please Help!!

• Jun 23, 2015 - 20:21

Okay, so I'm really annoyed. I posted a forum about this the other day, but it's occurred with another couple scores. Sometimes Musescore will crash, and sometimes it just states that it cannot read the file. I put HOURS of work into these scores for my school and other people who pay me to write. As a student, I don't have the money to afford fancy software like Finale or Sibelius. And Musescore has been a huge help to me in the past, but this is getting ridiculous. I currently have 2.0.1 running on a Windows 8 OS. Any suggestions on how to fix the problem? I can't keep losing work like this. The files I've included are the EXACT files I try to open. Could this just be a matter of Windows 8 not being strong enough to run Musescore properly?

Attachment Size
Insight.mscz 270.1 KB
Pokemon.mscz 162 bytes


Pokemon is corrupted beyond repair - looks like a system crash or disk faiure or other catastrophic problem occured while saving it.

Insight continues to open just fine for me except for the corruption which we have already discussed the fix for. Have you tried installing a nightly build to see if the file loads for you there?

In reply to by Jaqchue

The nightly builds are available using the "Download" link in the menu at right of this page; scroll down to find them.

I would assume there are disk diagnostic/repair tools provided by Microsoft that can be accessed either through the Control Panel or by right clicking the drive while viewing "My Computer" in Windows Explorer, or whatever the Windows 8 equivalent of that is. I primarily use Linux (Ubuntu) these days, but was a Windows user for the past 20 years. My Windows 7 machine is currently down for the count, but I'm hoping to get it back up and running soon.

In reply to by Jaqchue

Me neither, but while waiting to see to if someone can reproduce the crash under a debugger or otherwise get a stack trace - anyone? - we can try some process of elimination. Here's a few versions to try, where I have removed part of the content to see if we can narrow down where it might be. Do any of these work?

In reply to by Jaqchue

The first deleted the linked parts. The others started with that theh split the score in halves - first half / second half (deleting measures) and top half / bottom half (removing instruments). If the frist worked, so would the rest, but the others were there in case the first didn't. Now you'll jus have to regenerate the parts and hoep for the best - saving backups often.

And I guess we've learned that whatever the problem is, it had to do with the parts, not the score itself.

Is the attached file working better?

I don't use Windows but it seems to me most complaints of this nature are from Windows users. This could, of course, just mean that there are many more Windows users than Linux users, but it could mean that either MuseScore or Windows aren't saving files properly.

Regardless of blame, if you're work is important then you need to back it up. Consider your hard drive about as safe as a blackboard and just as vulnerable to someone or something wiping your work out without you ever knowing why it happened.

Attachment Size
Insight_3.mscz 270.55 KB

In reply to by Jojo-Schmitz

The original didn't crash for me either but it did have a corruption with 5/4 in Voice 2 on the Drum stave.

I think MuseScore has a problem here given the number of times that these corruptions occur and the number of times it seems related to too many notes or rests in Voice 2. I wonder if removing the ability to delete rests in Voices 2,3,4 might stop it? Maybe replacing it with an option to show/hide rests in other Voices by default?

Second to that, though, is the suggestion that something is not right with the OP's machine in that the first file was lost without trace. This could be a MuseScore thing, too, but if it is happening all the time then one thinks about disk drive or RAM problems or an operating system delayed-write issue.

In reply to by underquark

In my system, with Windows 8.1 and MuseScore 2.0.1 (and also commit 90e7a5f ) both the original and the one from https://musescore.org/en/node/66396#comment-302621 crash.
When I try to open these files under Linux Mint 17.1, self-compiled 671b10a26 I get into an infinite loop.
The problem is related to hairpins. The crash (Windows) and the infinite loop (Linux Mint) both happen while iterating on the next step in the loop inside function checkSpanner at line 2792 of edit.cpp:
for (auto i : _spanner.map()) {

EDIT: Under Linux Mint I am compiling with Address Sanitizer turned on, gcc 5.1.0 and Qt 5.4.1.

In reply to by Marc Sabatella

...Well, actually I am quite stuck in finding where the corruption of the spanner map is taking place.
What I can see is that before the crash the console outputs:
Debug: HairPin ticks changed, 245760 -> 247680
Debug: HairPin ticks changed, 245760 -> 247680

The spanner map at the beginning is 127 elements long. When it crashes/infinitely loops the spanner map is 2 elements long. It is probably the spanner map of a single part score instead of the full parent score.

In reply to by ABL

The debug message is perhaps an issue, but the case it is detecting does happen from time to time - I think mostly places where spanners start in one voice but end in another or something like that. Changing the tick count shouldn't affect the map, though. If do wonder about the management of the "dirty" flag though and if somehow that is causing a problem.

My understanding is that we aren't supposed to be deleting spanners during that loop - instead, we build a list (sl) of spanners to remove later. However, I wonder if spanners are being removed by some function within the loop because of that dirty flag.

The code that outputs that denug message is spanner.cpp, line 543. If you comment out the setTicks() call, does anything change about the behavior?

In reply to by Marc Sabatella

If I comment out that line in spanner.cpp, under Linux the infinite loop disappears but under Windows I still see the same problem as before.

EDIT: Well, not exactly. I see the same problem when I run MuseScore under Application Verifier, but sometimes it opens the score when I run it normally (and sometimes it crashes).

In reply to by Jojo-Schmitz

After some investigation, I know where the spanner map is getting corrupted.
If the condition at line 2818 of libmscore\edit.cpp is true,
if (s->tick2() > lastTick)
then line 2819 is executed:
s->undoChangeProperty(P_ID::SPANNER_TICKS, lastTick - s->tick());
this calls function ChangeProperty::flip() at line 3315 of libmscore\undo.cpp.
This function removes the spanner and adds back a new spanner with the corrects ticks.
This changes the spanner map while being inside the loop over the spanner map elements.
I don't know what could be the best thing to do to fix this bug. In principle it happens only if there is some sort of corruption (?) in the initial score, i.e. tick2 extending beyond the last tick.

In reply to by ABL

Yes, on initial read of a score, it seems this should not happen, so probably there is some sort of corruption. I'm guessing this line was designed to handle the case where time was removed (eg, a measure deleted) at the end of a file, and a volta or similar line needs to be shortened. Which makes me think you may have also just found the cause for #63231: Changing "Actual Measure Duration" under a volta causes crash - another crash I could not reproduce!

I guess we could, rather than change the tick count within the loop, build another list of spanners that need changing.

In reply to by Marc Sabatella

If I comment out that line so I can see the too-long hairpins, I can see the problem more clearly. In measure 25, many of the parts have hairpins. However, some of these (eg, bari sax) occur in measures that actually begin multimeasure rests, and somehow, two copies of the hairpin have come into existence - one for the mmrest, one for the underlying measure. And this is confusing the code that calculates the end element. With the offending line commented out, the score laods fine, but the parts in question all show a hairpin extending the entire duration of the score starting at measure 25, in addition to the regular one.

So I think there is probably an issue somewhere in the management of spanners with respect to mmrests and/or part generation that led to this issue in the first place, although so far I haven't been able to reproduce this. Jaqchue, do you know of anything unusual that you did or that happened involving the diminuendos in measure 25? Maybe something involving copy & paste?

Anyhow, I can definitely fix the loop to not try to fix these right away, and hopefully that also fixes the other issue I mentioned. It would still be useful to try to come up with steps to reproduce this duplicate-hairpin issue though.

In reply to by Marc Sabatella

I have submitted a PR that should fix the crash:


It would still be good to understand how to reproduce the probem that triggered this - hairpins duplicated in measures with multi-measure rests. My PR here will allow the score to laod, and you'll see the way-too-long duplicate hairpin in the parts where the measure 25 begins a multi-measure rest. You can then delete it normally.

I also discovered what might be a related problem where if you delete a part that contains linked spanners, the spanners remain linked to those in the original score. So far no actual adverse affects, but it can't be good. I'll file that separately once I have precise steps to reproduce.

In reply to by Marc Sabatella

I'm not sure what I may have done at m. 25. I know the diminuendo is supposed to be a measure before where it is placed, on the whole note. However I'm not sure why it moved to a measure after.. This also occurs with a crescendo somewhere in the piece. The ascending C#-E-A pattern in the saxes, piano, guitar, and vibes should have it, but it is placed a measure after. I don't know what caused this error.

In reply to by underquark

There has been much discussion about the ability to delete rests, but for now, it seems to me that too many people depend on this to seriously consider it to disable it. And in any event, I don't think that is necessarily connected to many corruptions. Most involve voice 1 only.

We've fixed a number of corruptions since the release of 2.0 - pretty much much all the ones where anyone has found a reproducible series of steps to create them. Many of the corruptions you see here were actually created by 1.3 but not detected because the detection code wasn't added until 2.0. I am hopefuly there are not many things left that can cause corruption, and that we will be able to identify and fix them.

Do you still have an unanswered question? Please log in first to post your question.