Cannot Read File - long piece is unreadable and changed size to 1KB.
MuScore version 2.0.2 – Windows 8
Problem:
MuSc “cannot read file". The non-readable file now says it is 1KB, when it was much larger while it was working and readable.
Longer Description of Problem:
Composed fairly long piece. The day of composition and the day after, I opened and closed the individual file on MuSc, many times. Last time the file was opened was for a play-through, with no editing done to file. Two days later, having not opened MuSc in the interim (having changed nothing since the last working play through), I try to open the file but I get the message “cannot read file”. This problem-file was my largest mscz file, but it now says it is only 1KB.
Attempted troubleshooting:
- Found and tried the lettered automatic save files, “sc##.mscz” none are of the full version of the piece.
- Found last hidden backup file, “ .name.mscz, ” but it is of a much earlier version, that doesn’t help me.
Any ideas? Even if I can’t save this one, I’d like to know what the problem is, before composing other long pieces that might have the same problem.
Possibly related questions (while stumped and grasping):
- Is there a limit to the size of files supported?
(But why would this size limit kick in after two days , when it worked fine before that time?)
- Is there a limit to the total number/length of files I can have saved at one time, with the free version of MuSc?
Thanks,
-Zoney
Comments
Sorry to hear this has happened. If you are *sure* you didn't modify & save the file last time you accessed it, then I'm afriad there is really only one explanation - a disk failure. That is, a hardware problem, not software. However, it's probably more likely you did inadvertently make a change (even switching form page to continuous view counts as a change) and then save the file without remembering it. And if MuseScore happened to crash right at that moment, and it had been less than two minutes since you made the change so the auto-save version of the file was not available, then unfortunately this can happen. Although still, if the scenario were exactly as you described it, I'd expect the backup file with the "." to be valid. So something doesn't quite add up.
There are a couple of known bugs that can cause crashes mid-save. We've fixed the bugs we can for the next release and also made the save operation more crash-proof (so a crash mid-save won't corrupt your file), so the good news is, this won't be a problem much longer.
For now though, unfortunately, the backups you found are your best bet unless perhaps you had the foresight to have set up automatic backup that you can restore - or are using something like Dropbox or Google Drive that does this sort of versioning automatically.
There is no arbitrary size limit for scores, other than what is imposed by thr limitations fo your hardware (eg, available RAM and disk space). Also there is only the free version of MuseScore - there is no version of MuseScore you need to pay for.
In reply to Sorry to hear this has by Marc Sabatella
Thanks. Luckily for me, I made an audio recording of the piece along the way, but the score is gonesville.
I’m as certain as I can be that I didn’t modify it at all (it was in continuous page mode the whole time, didn’t change any notes, dynamics, etc) those last times I played it through. The program and file had been opened and closed many times without doing any adjustments. Also I had saved it, very-many times along the way, but the auto save/backup that is available is of such an early version, minus hours of work, and many hard-saves I did along the way.
In other words, I wrote four percussion parts first, then bass – less than 1 hour estimated writing time – then added three horn parts, cello, viola, three violins – let’s say total time 5-8 hours? (I’m fairly new to this type of composition and still learning the program! ;) –, then play-backs, edits, re-composition, re-arrangements – 6-10 hours – ...of course, then came time to add the dueling violin solos!! – say 10-12 hours writing time, after all, etc – then multiple play-backs, sometimes after closing the file, and Musescore, entirely.
The reason I outline that is to say that there were hours of time, between beginning stages of composition and the final play-throughs I described; and I saved it many times along the way; which is why it seems odd that the only auto save or backup I found has only -- four staves of percussion, and bass.
That’s the first hour of work backed-up, but nothing after that? Isn’t it strange that the auto save would be of such an early version? As if the auto saves I’d expect to be there, that would get me many levels closer to the finished product, also disappeared with the problem or corruption of the file itself.
Anyway, in the future I’ll try breaking the longer pieces into different files, so that if one of them gets corrupted, there will be others that hopefully will not.
Again, thanks for the response, and answering my questions.
In reply to Thanks. Luckily for me, I by zoney
I recently documented a situation in which MuseScore 2.0.2 got confused about the true locations of files. It opened and saved files successfully, but changed the path and filename. If I hadn't noticed what was happening, I'd have thought my files simply vanished. You may have encountered a different problem, where the file name is preserved (and so looks normal on tabs and the Open Recent menu) but the path is garbled.
Have you tried an exhaustive search of your hard drive for all .mscz files anywhere? Look for any files of the right large size and with modification times in the right range, regardless of what they're actually named. MuseScore has stuck my files in at least four locations on my computer, including the root of my D: drive.
This sort of thing seems to happen a lot, judging by the number of reported incidences on the forum. Thankfully it doesn't seem to affect me but perhaps it's because I use ubuntu or maybe I've just been lucky.
There seem to be several areas where the saving of MuseScore files is vulnerable to OS vagaries, hardware problems, power surges etc.: the file is first saved to memory then compressed and then it's saved to disk but in some OSs it's left hanging around before it is actually written to disk and problems can arise at any of these stages.
If these issues affect you (or if you'd rather they didn't affect you), I'd suggest saving as an uncompressed file (MSCX) and periodically saving your work with a different filename (perhaps with the date and time incorporated in the title such as "MySong 20160206_0015", "MySong 20160206_0121".
Saving as an uncompressed file gives you the chance of at least being able to read some of a damaged filed (as opposed to trying to reconstruct a compressed file which is rarely possible) and saving multiple files is just common sense.