Auto save feature

• Mar 6, 2018 - 18:38

Auto save would keep scores safe from any technological issue/situation! Please add!!


Comments

Autosave is already set by default, at two minute intervals. So you are already reasonably protected. If you lose power, or your computer or MuseScore crashes, then the next time you start MuseScore, it will offer to restore your last sessions, and you'll find all but the last two minutes of work intact. Do a "save as" to place this recovered file somewhere other than the internal place it might otherwise be using, and you're good to go.

In reply to by penne vodka

Autosave cannot harm your score, it does not touch the file itself. But it does trigger a full relayout (or two) of the entire score, so if the score is large enough that saving it takes a noticeable amount of time, you might not want have that delay kick in every couple of minutes.

So to be clear: you should not "trust" autosave to actually save your score normally, that is not its job. You should always save normally, autosave or not. Autosave simply saves an extra copy of your score every two minutes.

The only way you could lose more than two minutes of work if autosave is left on and at its default is if for someone reason you did not actually restore from that autosave. There have been issues in the past - mostly in MuseScore 2 - where the autosave file would turn out to be corrupt and thus unusable. Or you may have accidentally chosen "no" when asked if you wanted to recover your previous session. In either case, you might then have had to resort to the backup file - the one with the name starting with a period and ending with a comma - which represents the state of the file the first time you saved it during the previous editing session.

In reply to by penne vodka

My main reason for turning off auto save is that in version 2, in continuous view, when auto save kicks in the layout for page view was taking more than the 2 minutes between auto save sessions. As a result, I couldn't do anything. This was mostly due to the size of the scores I was working on. Romantic symphonies are huge.

At the time I posted this, I suspected that the files we continually see that consist of zeros was due to auto save kicking in at a bad time. I still don't discount that auto save kills some files, but I now know that some of the files full of zeros were created on systems that did not have auto save turned on.

I keep auto save turned off in version 3 because I don't like MuseScore deciding when I'm going to stop working (you cant do anything while your score is being saved) and I'm used to auto save being turned off.

I've occasionally lost data on a crash also, but I'm willing to live with the relatively little data I lose compared to the time I would spend looking at my cursor swirl because auto save kicked in.

In reply to by mike320

I would say it's not possible that autosave could result in the user's own file being empty, because autosave doesn't touch the user's own file. But... while it's true autosave doesn't touch the user's file, I do wonder what would happen if the user somehow managed to kick off a save operation during the autosave. Normally you can't because as you've seen, the interface is pretty well locked out, but blah-blah-"race-condition"-blah, there could conceivably be some rare corner case in which this did happen. That shouldn't in itself be a problem, but if there was also bug in the file buffering system within Qt or the OS itself that cause these simultaneous writes to interfere with each other, this could be the result. I consider all of that an extreme longshot - these case happen far more often (unfortunately) than that "doomsday" scenario would likely explain. But anyhow, it is at least within the realm of possibility. But not one I'd ever suggest anyone actually worry about.

In reply to by Marc Sabatella

I consider all of that an extreme longshot

Considering the number of scores posted on musescore.com and the number of downloads of MuseScore and the relatively few scores we see that are trashed, it does seems to be an extremely rare, though devastating, occurrence. It think the more likely scenario is that the user would save the file then auto save kicks in since it's difficult to make anything happen during auto save, though at least 1 or 2 keystrokes seem to be accepted once auto save kicks in so the user saving after auto save kicks in is not out of the question.

In reply to by mike320

My gut sense is that the number of empty scores we see here is far in excess of what would be expected if bugs in MuseScore, Qt, and the OS all happened at precisely the right coordinated instant to cause this. But it could certainly be worth someone's time to explore that theory, deliberately trying to trash a large score by saving during (or immediately before or after) the autosave. The good news is, if it's possible to reproduce the problem that way, it's probably relatively simple to figure out how to work around those Qt/OS bugs.

Realistically, though, I still suspect most of those empty scores will turn out to caused by one or more other bugs.

In reply to by Marc Sabatella

When autosave starts, it doesn't need any user info to do its job. It is perfectly able to perform what it does (full relayout followed by disk writes) from what is in memory.
So why doesn't it just save the memory content WITHOUT the long relayout operation ? Performing the relayout on the autosaved file content only when you actually read and use that file. Wouldn't the autosave be a lot quicker then ?

In reply to by frfancha

Saving is not just writing memory content in raw form, it's walking a data structure and writing specific tags for specific objects in a specific order. And as mentioned, in order for this to work correctly in the presence of multimeasure rests and/or hide empty staves (and perhaps other features) a layout can be required. But, the thumbnail at least could be skipped. So indeed there could potentially be room for optimization of that process.

I wish to control the updating of the date/time stamp in my scores. I do not wish it to be updated automatically by Musescore. I want it to be updated only when I edit and manually save a score. If this were so, I could use the date/time stamp to compare different versions of the 'same' transcription.
I have added $M $m to the footer of my scores and turned off Autosave. Still, the date/time stamp on my scores is updated even with no changes to the score and without me saving the score. For instance, it is updated whenever I merely open a score. It also happens when I am browsing a score, then click on a window in another application, then later click on the score to return to it. The date/time stamp is immediately updated.
How can I turn off this automatic update of the date/time stamp by Musescore?

With many thanks.

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