Lost changes in score with unrolled repeats

• Nov 28, 2021 - 16:59
Reported version
S2 - Critical

All that I wrote for the Saxophones got lost when I opened up the application a few hours after closing it. The score was back to how it was before I unrolled the repeats. I have found no way to get back what I wrote and I can't find any copies.

Attachment Size
blow_away_saxar.mscz 40.73 KB


Of course, you always need to save your work if you want to view it again after closing it - in MuseScore or any other program. You don't say if you saved it or not, or what filename you gave it if you did save it. But there is indeed an issue where if you neglect to choose a filename (eg, via Save As) after an unroll, MuseScore will not always succeed in the save, and in certain cases (apparently on macOS only?) may not even warn you you the save failed. Probably the first try at saving should automatically do a Save As, just as if you had created a new score. But for now, indeed, always "Save As" explicitly after unroll. See #289758: Save error with unrolled repeat version of score for more info.

In reply to by Jojo-Schmitz

Jojo wrote Workaround would be to use "Save as".

If you've used File>Parts to generate parts, use Save As from the main score to save the entire score. If you invoke Save As from a Part MuseScore will save the Part alone to a new score.

I wish MuseScore would offer a warning on this:

• "You are saving only this Part to a new Score. That always occurs when invoking Save As. To apply Save As to the whole score, return to score view first."

-- or --

• post a dialog that offers a choice a) Save As (Part only) b) Save As (Entire score)


In reply to by Marc Sabatella

The problem that many of us are coming up against here is that UI is misleading. We follow the usual conventions, which is to Save, and the UI does not tell us that the unrolled version (which we just spent a bunch of time editing) is not saved. Similarly, we are not warned when closing the unrolled score that it has not been saved.

You hit Save while working on the unrolled score, and it didn't save, and also you didn't receive any sort of error message? That's not the save for me. When I do "save as", it works normally. If I do a plain "save", I get an error message due to another bug - see #289758: Save error with unrolled repeat version of score. But it never just fails silently - either it works, or it tells you it failed.

Also, if I then try to close the file without saving, it definitely prompts to save.

If you still believe you are seeing a problem, please attach your score (the original version) and give steps to reproduce the problem, starting with the unroll. Then we can begin to investigate if there is is indeed some sort of case where the save silently fails.

Then please attach your score (the "rolled" version and precise steps to reproduce the problem (i.e.., beginning with "unroll the score", then telling us exactly which editing commands to do before trying to save, and how you are trying to save). I cannot reproduce this on Windows or Linux - for me, Save always fails with the message given, save as always works, simply closing the tab always warns.

I unrolled the repeat at the end of the enclosed score.
Got a new tab "_unrolled" shown as dirty with an asterix.
Saved (Command-s) and the asterix went away, suggesting a succesful save.
But no such file on the disk nor in the "Open Recent" list (the original is still included).
MacOS 12.6

Attachment Size
Stranger.mscz 115.12 KB

So, the save didn't first prompt for a filename? That is unusual, but maybe it has to do with where your default folder is. Be sure to do a complete system search using Finder - look for all files ending in ".mscz" in all folders, all drives - including hidden and system folders.

If you still cannot find it, probably best to make a screen recording so we can see what you are seeing. And also, be sure to ay what version of MuseScore - see Help / About. Current is 3.6.2.

In reply to by bkv_ykf3wdq-QHK3pzv

Not sure it helps, but trying to save the unroll file seems to be correlated with some errors in the logs:

Couldn't read values in CFPrefsPlistSource<0x15b805ef0> (Domain: kCFPreferencesAnyApplication, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): accessing these preferences requires user-preference-read or file-read-data sandbox access

container_create_or_lookup_for_platform: error = ((container_error_t)100) USER_HAS_NO_HOME_DIRECTORY

Very strange. Those log errors definitely seem significant. Seems macOS - or the Qt wrapper MuseScore uses to avoid relying on low-level system functions - might behave differently than other OS's when attempting to save a file with an empty folder name, putting an error out to console but not reporting the error to the application like Windows and Linux do (which is why they show a dialog box). That seems bad. But maybe it's specific to using Dropbox as your default folder? Worth asking on the forum to get feedback from other Mac users. Also maybe experimenting to see if a default folder not on Dropbox works differently.

Anyhow, right now, the unroll repeats command is not available in MuseScore 4 builds, O I can't check there. But hopefully when that command is made available again, we can try to make sure works on macOS / Dropbox, assuming we can figure out how to reproduce the problem to begin with. So thanks for your help!

So, I've done the unroll by hand now. Sounds like it would better disabled, or changed to apply to the original file.
Personally, I would always attach a directory to a file, especially as I'd expect to see it appear in the same place as the original.
That said, the only reason I'm unrolling is because I can't have parts played in selected repeats.

Applying to the original file would be disastrous people would lose their original version the moment they saved. Normally unroll repeats would only be to have a "playback only" version of a score, separate from the regular version used for all other purposes (print, PDF export, sharing online, etc).

The unrolled score isn't a file yet - it's just something in MuseScore's memory. Same as if you do File / New. But indeed, it would make sense for a save operation to default to the same folder that the original was in. Presumably when this command is implemented for MuseScore 4, that can be made to happen.