View Issue Details

IDProjectCategoryView StatusLast Update
0009215ardourbugspublic2023-06-17 19:56
Reporterahellquist Assigned Tox42  
Status resolvedResolutionfixed 
PlatformGNUOSLinuxOS Version(any)
Product Version7.2 
Summary0009215: Crash recovery session handling
DescriptionI frequently use my sessions for rehearsal or just goofing around. When playing soft synths, I change patches and sometimes att Tracks an busses that I don't intend to save to my current session.
No to the issue.

If Ardour crashes, I get the usual choice if I want to recover or load the saved state.

If i choose recover, I expect to get the last state of my session so I can keep on goofing or rehearsal.
Then when I quit, I expect Ardour to ask me if I'd like to save my recovered still dirty session of not.

Unfortunately, that is not how Ardour behaves since Ardour apparently commits the recovered session to the Session file as soon as one is recovering a crashed session.

My question is, Am I totally wrong in my reasoning that Ardour should not commit the recovered state to file until the user wants to quit?
Steps To ReproduceOpen a session. Change some stuff. Make Ardour crash.
Select recover when option is presented.
Try quiting the session without commiting the changes to the session file
Tagscrash, session



2023-01-30 13:28

reporter   ~0027260

Sorry for the spelling misstakes


2023-02-03 06:25

administrator   ~0027269

> Unfortunately, that is not how Ardour behaves since Ardour apparently commits the recovered session to the Session file as soon as one is recovering a crashed session.

That is indeed the case. and I think you do have a valid point.

OK. Let me elaborate:

Ardour periodically writes a ".pending" state (usually every 2 mins, and when rec-arming the session).

When loading a session and a .pending state file exist, there is the option to load this state ("recover from crash") instead of the main session file.

The .pending file is removed
1. when a session is closed (at exit, no crash)
2. when the session is saved. This can happen
 2a. manually (ctrl+S)
 2b. automatically after each record-stop
 2c. after a successful load of the .pending file
3. when a snapshot is saved or the session is renamed - both a special cases of (2a)

We can indeed get rid of (2c) and instead add

 2d. when the user chooses to not recover (ignore crash data)

There is still the edgecase of 2b. When your goofing around involves recording data, the session will be saved.
In theory rec-stop could just write to a .pending safe rather than overwriting the session, but I am not [yet] convinced that is is a good approach.

All that being said, why don't you use a snapshot when playing around?


2023-02-03 06:42

administrator   ~0027270

Amend the above:

2b. automatically after each record-stop, and also after "remove last capture" (so that the session does not end up referring to non-existent sources)
2f. session is also saved after a Session > Cleanup


2023-02-03 06:58

administrator   ~0027271

I have just made those changes (Ardour 7.2-194-g14606ac655)

Rec-stop now also only writes a pending (recovery) file. This is somewhat dangerous and I may revert that change pending further discussion.


2023-06-17 19:56

administrator   ~0027789

You can now recover, goof around, and quit without saving.
On next reload this returns you back to the last explicit save.

There are 2 notable exceptions: removing tracks, and session-cleanup save the session. There is a confirmation dialog "..this operation cannot be undone..", so you can opt out

Issue History

Date Modified Username Field Change
2023-01-30 13:26 ahellquist New Issue
2023-01-30 13:26 ahellquist Tag Attached: crash
2023-01-30 13:26 ahellquist Tag Attached: session
2023-01-30 13:28 ahellquist Note Added: 0027260
2023-02-03 06:25 x42 Note Added: 0027269
2023-02-03 06:42 x42 Note Added: 0027270
2023-02-03 06:58 x42 Note Added: 0027271
2023-02-03 06:58 x42 Assigned To => x42
2023-02-03 06:58 x42 Status new => assigned
2023-06-17 19:56 x42 Status assigned => resolved
2023-06-17 19:56 x42 Resolution open => fixed
2023-06-17 19:56 x42 Note Added: 0027789