View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009215 | ardour | bugs | public | 2023-01-30 13:26 | 2023-06-17 19:56 |
| Reporter | ahellquist | Assigned To | x42 | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU | OS | Linux | OS Version | (any) |
| Product Version | 7.2 | ||||
| Summary | 0009215: Crash recovery session handling | ||||
| Description | I 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 Reproduce | Open 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 | ||||
| Tags | crash, session | ||||
|
|
Sorry for the spelling misstakes |
|
|
> 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? |
|
|
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 |
|
|
I have just made those changes (Ardour 7.2-194-g14606ac655) https://github.com/Ardour/ardour/commit/054e1c3c123a1cfb0c79c448eae0511ccd2d9178 https://github.com/Ardour/ardour/commit/14606ac655479769ed79bb905725a1217fd073ad Rec-stop now also only writes a pending (recovery) file. This is somewhat dangerous and I may revert that change pending further discussion. |
|
|
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 |
| 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 |
