View Issue Details
|ID||Category||Date Submitted||Last Update|
|0006084||bugs||2014-12-24 02:32||2020-04-19 20:16|
|Fixed in Version|
|Summary||0006084: Autosave/periodic backups overwrites project file, doesn't save often enough.|
|Description||At the moment, Ardour (revision 3.5-403-gec2cb31) makes semi-periodic backups and it saves them to a file project.ardour.bak, but it *also* saves them to the main project.ardour file - which means if you decide after a large number of edits (more than the undo history) that you don't want one of your changes that you made since a manual save, then you're stuffed, and you can't revert to the last manually saved version.|
Also, recently I was making a track with lots of MIDI editing, and after making a large number of changes to the track, Ardour crashed, and I lost all of it apparently because MIDI editing does not trigger the periodic backup.
Optimal behaviour would be something like:
1. Backups are made to `project.ardour.autosave` or similar (I think autosave is a better terminology - backups shouldn't be automatically overwritten).
2. `project.ardour` is only written to when the file is saved manually.
3. Anything that gets added to the undo list is included when calculating when an autosave should trigger.
4. How many events are needed before an autosave is triggered should be customisable (maybe 20 by default?)
5. Ardour should write the project identifier to a file like `~/.config/ardour3/current` when a project is opened. It should delete that file after closing a project cleanly. When Ardour starts, it should check to see if that file exists, and if it does, it should offer to try to recover the crashed session from the `project.ardour.autosave` file.
|Tags||No tags attached.|
I noticed something potentially related: it often takes plenty of Undos to undo a single action. (I do mostly MIDI editing)
Another thing is the velocity scroll: each step of the scroll is considered as one action... :)
||http://tracker.ardour.org/view.php?id=5608 would probably fix the velocity scroll issue|
||rgareus said on IRC that periodic backups actually every 5 minutes. Whether it's time- or event-based isn't really that important, but the "periodic backup" option *was* on for that MIDI editing session I mentioned, and it didn't create a backup. So maybe there is another bug there? Hard to track down though.|
without thinking about it too much I mostly agree with your description of the optimal behavior. I think that the implementation of recovery in point 5 could be improved though.
If Autosave is saving to a separate file then perhaps just delete that file on a successful manual save or session close. If the autosave file exists when reopening a session then offer to recover from it.
The saving of the `project.ardour` file might be related to 0005939
||@timbyr: That's what ardour does already (or is meant to do). But it doesn't current have a way of keeping track of what session was open during a crash, so you have to manually select the session before Ardour realises it has crashed.|
Ardour never lost a capture for me, even when a crash happened during recording.
However many times I had no crash recovery for MIDI editing, automation editing or mixing work, which is not great.
I'd be all for making crash recovery save more often.
I ran into this recently - and wrote a script to save snapshots every minute, regardless of what else was happening. https://ajg.net.au/content/creating-automatic-backups-ardour
It would be nice to have some more options/control over the automatic saves that are built-in though, and yes, I suspect they just don't happen if you haven't recently recorded or rolled transport.
Fixed since 6.0-pre0-2203-gae2b6e6b09
Previously every transport-stop deleted periodic backup save (since originally they were only intended to guard recording).
Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.
|2014-12-24 02:32||naught101||New Issue|
|2014-12-24 02:38||florianb||Note Added: 0016082|
|2014-12-24 02:41||naught101||Note Added: 0016083|
|2014-12-24 02:47||naught101||Note Added: 0016084|
|2014-12-24 03:05||timbyr||Note Added: 0016086|
|2014-12-24 03:11||naught101||Note Added: 0016087|
|2014-12-24 03:13||naught101||Note Added: 0016088|
|2018-04-13 22:09||unfa||Note Added: 0020258|
|2018-06-04 10:30||agittins||Note Added: 0020286|
|2018-06-04 13:55||unfa||Note Edited: 0020258||View Revisions|
|2018-06-04 18:02||agittins||Note Edited: 0020286||View Revisions|
|2020-04-05 14:50||x42||Assigned To||=> x42|
|2020-04-05 14:50||x42||Status||new => resolved|
|2020-04-05 14:50||x42||Resolution||open => fixed|
|2020-04-05 14:50||x42||Note Added: 0021181|
|2020-04-19 20:16||system||Note Added: 0023353|
|2020-04-19 20:16||system||Status||resolved => closed|