**Reoccurring Problem**: Cannot Open Scores!! Please Help!!
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 |
Comments
I do not think I can help you, but
The first file appears empty, look for the backup:
https://musescore.org/en/handbook/file-format-0#musescore-backup-files ;
The second has a problem to measure 8 (see attached image) and checks if the *.mscz file is correct.
In reply to I do not think I can help by Shoichi
I'm aware of Insight's corruption, however I cannot even launch the file to correct it. It crashes Musescore
Do you transfer the files via USB keys ? Is your hard drive close to being full?
In reply to Do you transfer the files via by [DELETED] 5
I don't understand what you mean by USB Keys. Do you mean a flashdrive? I havent transfered any files onto this computer. And I do not believe my hard drive is close to being full. It says I have 24.6 GB left on my C: Drive.
In reply to I don't understand what you by Jaqchue
It's possible there are bad sectors on the disk and that is why writes are sometimes resulting in corrupted files. It could be worth running some disk diagnostics.
In reply to It's possible there are bad by Marc Sabatella
How do I go about running disk diagnostics?
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 Pokemon is corrupted beyond by Marc Sabatella
What is the nightly build? How do I get it? And what OS do you use Marc?
In reply to What is the nightly build? 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 The nightly builds are by Marc Sabatella
Is the nightly build the same as 2.0.1? I don't see a separate option for a "nightly build" ---- EDIT: Just kidding, had to scroll down more. Thank you for your help! Will update as to whether or not this works
In reply to Is the nightly build the same by Jaqchue
Scroll all the down to here:
https://musescore.org/en/download#Nightly-versions
In reply to The nightly builds are by Marc Sabatella
Installed and ran the nightly build. Insight crashed it. I also ran a diagnostics test on my disk and no errors or corruptions were found. I'm really stuck here. I have no idea what it could be.
In reply to Installed and ran the nightly 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 Me neither, but while waiting by Marc Sabatella
I was able to open all of those files!!! What did you do to fix it?
In reply to I was able to open all of 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.
In reply to The first deleted the linked by Marc Sabatella
I couldn't thank you enough! I'll be careful when making and editing parts.
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.
In reply to Is the attached file working by underquark
Thank you, I will back it up from now on. Your file crashed Musescore however
In reply to Thank you, I will back it up by Jaqchue
Not on my system (xubuntu 15.04, build bf8dc84) - I did check it after posting - so it might be a Windows 8 thing or something else on your machine. If other Windows 8 users could try opening it...
In reply to Not on my system (xubuntu by underquark
Doesn't crash in Windows 7 (Enterprise, 64bit), MuseScore 2.0.1. But the original from the 1st posting doesn't crash here either
In reply to Doesn't crash in Windows 7 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 The original didn't crash for 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 In my system, with Windows by ABL
This is great information, thank you! Do you think you have enough to go on to be able to identify and fix the root problem here? I guess _spanner.map() has become corrupt somehow?
In reply to This is great information, 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 -> 247680Debug: 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 ...Well, actually I am quite 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 The debug message is perhaps 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 If I comment out that line in by ABL
probably something from an entirely different place corrupts the spanner map, with different consequences on Linux or different version of Windows. Air humidity, moon phase and what you last had for dinner probably plays a role too.
In reply to probably something from an 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 After some investigation, I by ABL
Hmm, maybe just restart the loop and possibly mark the spanner map volatile?
In reply to After some investigation, I 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 Yes, on initial read of a 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 If I comment out that line so by Marc Sabatella
I have submitted a PR that should fix the crash:
https://github.com/musescore/MuseScore/pull/2094
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 If I comment out that line so 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 The original didn't crash for 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.