Scores corrupted beyond repair, containing nothing but zeros

I don't have steps to reproduce but a couple of ideas to investigate:

• Is it possible that autosave kicks in while saving a file via Save as ? What would happen ?
• Review the save process and make sure we catch all possible errors and display a dialog.

AFAIK, this issue relates to incorrectly saved files. I believe that the reason is that sometimes MuseScore incorrectly saves files (file access issues?).

DOC: From https://musescore.org/en/node/271294: user didn't suffered a crash. Just did a Save and then reopened the score.

Who knows, I think that unless some kind of detailed tracing is written, only for the code related to the autosave/the explicit user saves/the zip write, we depend on the user's memory for the actions done before the problem...

Ill let my MuseScore opened all the weekend in my computer, with a score opened of course. Let's see what happens after

Are these old issues solved? https://musescore.org/en/node/15059 , https://musescore.org/en/node/15264 ?

and https://musescore.org/en/node/150281 ?

What's the below TODO: in autoSaveTimer? (code from 2.2.1 branch) ,
https://github.com/musescore/MuseScore/blob/2.2.1/mscore/musescore.cpp#…

//---------------------------------------------------------

void MuseScore::autoSaveTimerTimeout()
{
bool sessionChanged = false;
foreach (Score* s, scoreList) {
if (s->autosaveDirty()) {
QString tmp = s->tmpName();
if (!tmp.isEmpty()) {
QFileInfo fi(tmp);
// TODO: cannot catch exeption here:
s->saveCompressedFile(fi, false);
}
else {
QDir dir;
dir.mkpath(dataPath);
QTemporaryFile tf(dataPath + "/scXXXXXX.mscz");
tf.setAutoRemove(false);
if (!tf.open()) {
qDebug("autoSaveTimerTimeout(): create temporary file failed");
return;
}
s->setTmpName(tf.fileName());
QFileInfo info(tf.fileName());
s->saveCompressedFile(&tf, info, false);
tf.close();
sessionChanged = true;
}
s->setAutosaveDirty(false);
}
}
if (sessionChanged)
writeSessionFile(false);
if (preferences.autoSave) {
int t = preferences.autoSaveTime * 60 * 1000;
autoSaveTimer->start(t);
}
}

Next corruption reports should tell, Jojo, in my opinion we must ask this one you mention, and perhaps other things about the user's environment (antivirus/ slowness etc.)

But If there would be still some points in file.cpp (or others) that are not catching or propagating exceptions "upside-down".. I would prefer code that fails or crash "blatantly" that "silently" (haha)

Pair of remarks from support system about the issue:

Hello, for the first time I've had serious problems with working on a musescore document (Version 2.1, MacOs 10.12.6). After two hours of composition work I saved and closed the document. Later, when I opened the file again, half of the work was gone, i. e. part of it had obviously not been saved (without a warning by closing).

This guy created the forum post: https://musescore.org/en/node/269405.
Hi there "Cannot read file C:/Users/kevin.LAPTOP-SV2AAG16/Desktop/HSC MUSIC/New Ragtime HSC.mscz:" happens when i attempt to open my score up!
I've been using the plain MusoScore2, and i was saving the same as i always do (when i was finished id hit save and close done.). Started this score around end of last year and everything was perfectly fine. This has happened to me before (with other scores) but i hadn't really cared much because i had finished the previous scores and had already handed them in, but i really need this one for an assessment. Ill attach the score it just says that it cannot read file thats all!

Yes, I have been using MuseScore for all 8 years. Have had this problem once before, but it was resolved through Cloud storage. Sadly, that didn't work this time.

attaching one 0-filled score from user report, https://musescore.org/en/node/271294

Jojo, do you know if any MuseScore developer is actually looking now at this issue, to the code pointed above (for example)?

I'm regrettably not a developer (programmer), but would like to help. Regarding the attachment, I think having a sample in the issue should be mandatory, to not lose time searching for examples in the forum threads. I know that apparently is of no use.

Another idea. It would be useful to ask the users experiencing this issue, if they were on Windows, to consider the chance to submit to this Issue an attachment containing an export (in text or CSV format for example) of the Application Event Log of Windows, more or less at the time of the problem (some time before, ideally). Sometimes, information in this log could give a hint of performance or instability problems in the background.

By exporting the log (or just a part of it) as a text or comma-separated (CSV) files, the user can sanitize information from his/her computer not relevant to the issue, before attaching here.

Nicholas,

I just did this test (with 2.1), regarding your first point:

-Opened a large ( about 1000 measures) score. Naturally, it lasted several seconds to load. Changed the autosave time to 1 minute.

-Started a clock in my computer. Did a small change in the score, so to trigger the autosave at the 1 min mark.

-1 secons after the autosave kick in, checked via a cmd window, that MuseScore still didn't written the temp file. 5 seconds after the 1-minute mark, checked that MuseScore created a 0-byte size tempfile , and , at the same time, the UI was freezed (blue circle rotating). After 10 seconds, the tempfile was finally written (about 500 Kbytes), and the UI was again available (responding to menu selections, etc.)

-Lastly I did another change, waited until the kick-in, and when I was ready to enter a Control-S (to save) at the austosave time, again the UI was freezed (again until the tempfile was written)

So, at a first glance, it appears that a collision between a UI Save/Save As and the autosave tempfile, per se, is not feasible. iSeems the running thread who writes the tempfile prevents any action from the UI, blocks it, until the tempfile is written on disk.

So, it appears (to me) that Score::saveCompressedFile in scorefile.cpp would be a good candidate to put a log or trace. I don't think it would that difficult to implement, if you are writing for example the "session" file, you could just write (only to disk, in a logfile) a log of the actions performed inside this function, so, in the case of a user reporting a 0-bytes score, at least have a trace of the inner workings to pinpoint where it halted.

Am I wrong?

@mid1972

If I tried the test you just did, my system would freeze. It would take more than a minute to auto save the file and every minute it would attempt to once again auto save the file and I would get the windows blue circle of death until I forced MuseScore to close. I know, I've tried it. So on your system, you cannot interrupt the autosave, that doesn't mean someone with a slower operating system like mine would not be able to do that.

@Mike, could you actually did a Save while the blue circle was visible? if so, tell me.

The blue rotating circle indicates MuseScore is busy doing the operation, and it won't accept any input from the user at all (unless you forcibly kill the MuseScore process of course). What I was interested is to check is the first point @lasconic suggested, if the autosave operation is blocking, and it's appears that yes (at least in my system!)

I can reproduce this every time: until the autosave finish, no UI input is allowed, I think this is good.

Again, this is not to prove the problem is that delay or blocking behaviour of the autosave. My point is to check that maybe a further investigation (ie: traces) would be needed on scorefile.cpp - Score::saveCompressedFile, which is a common function, not only used by the autosave AFAIK.

I don't know how you tested whether you can have the save and auto save interrupting one another. Explain and I will run tests.

I turned the auto save on my computer off, because the score I'm working on right now takes about 4 minutes to save, so I NEVER want auto save to kick in. I save it when I'm ready to take a break. I'm curious what would happen if I had auto save turned on and it kicked in while my score was saving. You mentioned a delay between auto save kicking in and you being locked out, I wonder if the delay is long enough on my system to cause problems. I'm willing to test these possibilities, but of course they will take a little more time on my system than yours.

While the circle of death is active I use the task manager to force MuseScore to stop. Fortunately I get the "Would you like to restore your last session?" message.

Re: "I don't know how you tested whether you can have the save and auto save interrupting one another. Explain and I will run tests."

Mike, I didn't said that! it's precisely the contrary I'm verifying. I was precisely interested to test that, and I couldn't, due to the behaviour presented.

Re: "I'm curious what would happen if I had auto save turned on and it kicked in while my score was saving. You mentioned a delay between auto save kicking in and you being locked out, I wonder if the delay is long enough on my system to cause problems."

In my system, what it happens is that the autosave kick-in blocks the UI (and presents the blue circle). And, just the moment it finally writes the tempfile, the blue circle dissapears and the UI resumes to be responsive. So I couldn't, of course, make a Save/Save As during that blockage. That's all.

And that's the reason I think that tracing/logging the actions of scorefile::saveCompressedFile would give a hint to what would happened in the case of a "0-bytes" score, simply.

I understand what you are doing now. I'm sure I can test if autosave can kick in while a save as is being executed and find the results. I need a day or two to test it. I'm almost finished with my score, I'll save it to MuseScore.com so it won't matter if it gets clobbered and replaced by zeros.

@GFord...

Recently you've encoutered 2 zero-filled scores.
"Cancion .mscz" from here:
https://musescore.org/en/node/271294
and "Medley.mscz" from here:
https://musescore.org/en/node/269305

Are there similarities between scores? For example, did each score:
Contain multiple instruments?
Any lyrics?
Were part tabs generated and saved with each score?

Regards.

Recent fixes by Dmitriy and others might have finally dealt with this, but I guess only time will tell.

Happened in 3.6, had to go through the backups folder to find a backup. Score was solo piano
The uncorrupted file (as recovered from the backups) is attached too.
Note that, after recovering from the backup, the text was in Edwin, instead of FreeSerif. I had to reset style settings to fix that.
Edit: To clarify, I use Windows 10

Interestingly I've not had this issue, and also never used MuseScore on Windows (only ever on Linux). I'd be curious to know what operating system people who do experience this issue are using - i.e. does it only happen on Windows? Does it only not happen on Linux? Are Mac users affected?

Something to think about.

I think a lot of the reports have come from people who didn't say what OS they were on, so it's hard to be sure. But from memory, it does seem that all of the ones who did say were on Windows - I can't recall any reports from people who specifically said they were on another OPS. I guess someone could visit all those "What links here" posts to see, and request more info from those who didn't say.

can anyone help me to recover this?

does anyone know how to fix this

This is an empty file.
Lavoisier told us that only God can create out of nothing, and unfortunately God isn't a member of the MuseScore team anymore.