User story / context
System crashes can happen, whether it's the GPU / display server going kaboom, or Linux being crap at handling out-of-memory conditions (examples: 1, 2, 3), Reco should allow recovering previously interrupted recordings from the time of the crash.
For instance, when I opened a new tab in my browser while recording today, the Linux kernel entered a thrashing situation for many minutes as my RAM was full (and the OS is too stupid to tell the browser that it can't afford a new tab), and when it finally killed Firefox, I was left in a situation where Reco was stuck with a blank recording graph (i.e. no histogram bars) and I couldn't press the Resume or Stop buttons: the app was frozen/unresponsive (Mutter gave me the option to Force Quit it, indicating that the app's mainloop had frozen).
Potential improvements
I'm wondering if Reco could somehow detect those "stuck mainloop" conditions when something else in the OS blocked it for too long, but I doubt that's possible.
Failing that, it should let me recover my work when I kill the app and launch it again.
Thankfully, as I discovered today, Reco does write to disk continuously as it records (i.e. it's not just all in RAM), as there are a bunch of recorded opus files in ~/.var/app/com.github.ryonakano.reco/cache/reco_SOMEUNIXTIMESTAMP.somefileextension:
I was very happy to discover that I can recover my incomplete recording through the file manager, but non-technical users would never think of that trick.
Could Reco detect the presence of those incomplete files, and, on startup, prompt the user with a recovery dialog offering to do something about it:
- Save it/them to the recordings folder with the proper human-readable standard filename?
- Optional: maybe even resume recording on the last file (I don't know if that's possible or safe), if the modification date is within the last 15 minutes of the current time?
User story / context
System crashes can happen, whether it's the GPU / display server going kaboom, or Linux being crap at handling out-of-memory conditions (examples: 1, 2, 3), Reco should allow recovering previously interrupted recordings from the time of the crash.
For instance, when I opened a new tab in my browser while recording today, the Linux kernel entered a thrashing situation for many minutes as my RAM was full (and the OS is too stupid to tell the browser that it can't afford a new tab), and when it finally killed Firefox, I was left in a situation where Reco was stuck with a blank recording graph (i.e. no histogram bars) and I couldn't press the Resume or Stop buttons: the app was frozen/unresponsive (Mutter gave me the option to Force Quit it, indicating that the app's mainloop had frozen).
Potential improvements
I'm wondering if Reco could somehow detect those "stuck mainloop" conditions when something else in the OS blocked it for too long, but I doubt that's possible.
Failing that, it should let me recover my work when I kill the app and launch it again.
Thankfully, as I discovered today, Reco does write to disk continuously as it records (i.e. it's not just all in RAM), as there are a bunch of recorded opus files in
~/.var/app/com.github.ryonakano.reco/cache/reco_SOMEUNIXTIMESTAMP.somefileextension:I was very happy to discover that I can recover my incomplete recording through the file manager, but non-technical users would never think of that trick.
Could Reco detect the presence of those incomplete files, and, on startup, prompt the user with a recovery dialog offering to do something about it: