Auto save feature
Auto save would keep scores safe from any technological issue/situation! Please add!!
Do you still have an unanswered question? Please log in first to post your question.
Auto save would keep scores safe from any technological issue/situation! Please add!!
Do you still have an unanswered question? Please log in first to post your question.
Comments
Go to Edit>Preferences: Autosave function is there. Select and set.
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 Autosave is already set by… by Marc Sabatella
I have had several major losses of updates, and now re-name each revision because I don't trust the system --even when choosing 'Save' manually.
In reply to I have had several major… by ArnePianoCanada
I don't trust auto save one bit. I have it turned off and manually save my scores. The only time I lose data if when I have a power outage. I'm used to saving often so I don't lose much data.
In reply to I don't trust auto save one… by mike320
@mike320
Yes. I recall losing more than the last 2 minutes on a crash at times. I manually save as well, but I'm not clear as to why I should turn off auto save too. Is it a matter of resources?
In reply to @mike320 Yes. I recall… 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 @mike320 Yes. I recall… 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 My main reason for turning… by mike320
I see... thanks.
In reply to My main reason for turning… 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 I would say it's not… 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 I consider all of that an… 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 My gut sense is that the… 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 When autosave starts, it… 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.
In reply to Saving is not just writing… by Marc Sabatella
Saving is not just writing memory in raw form.
Well that's true for a true save.
But why couldn't it be memory in raw form for the autosave feature, up to the recovery process to rebuilt the file based on that ?
In reply to Saving is not just writing… by frfancha
Because pointers.
In reply to Because pointers. by Marc Sabatella
Pointers explain why a "pure" raw memory save doesn't work, it doesn't explain why a full relayout is necessary.
In reply to Pointers explain why a "pure… by frfancha
Correct, my previous response already explained that, and observed that there could well be an opportunity to optimize things to avoid this need.
In reply to Autosave is already set by… by Marc Sabatella
I just had a crash, and when I tried to restore my previous session it just kept re-opening the same dialog box to select restore. I could never actually open my file. Ah well, more opportunity to practice!
In reply to Autosave is already set by… by Marc Sabatella
How to delete the autosave score, can you please tell me?
In reply to How to delete the autosave… by kaisarsihaloh
See:
https://www.computerhope.com/issues/ch000743.htm
In reply to Autosave is already set by… by Marc Sabatella
nvm, can't delete a comment
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.
In reply to I wish to control the… by Warren-Keith
Those timestamps are updated whenever you make any modification to the score. But as long as you don't save it (autosave doesn't come into play here at all), the mscz file won't get updated, so opening it again would still show the old timestamp.