Feature request: Add delay to recording stop after disarming. about wtfos

[delfer]

+1
Most of my records miss stats screens, because Googles stops recording immediately.

[LouDnl]

It's been a while since I looked at the code, so long in fact that I didn't even try the OSD recording yet. This means at this moment I have no idea how the OSD recording interacts with the auto record. Aside from that, at this moment the auto record automatically starts as soon as it detects signal and stops when signal is lost. There is no separate timer, except for the timer hook we use for prolonging recording.
This feature along with autorecording on a fullsize AU is still on my todo list which unfortunately is a bit dusted due to other projects, work and private life :)

[j005u]

Yeah the point of the tag was that maybe between you and @Knifa we can work out why the two don't work well together. For Knifa's benefit: https://github.com/loudnl/wtfos-auto-record

[robertrypula]

Oh yeah!! This would be something! Also I miss the ability to record the OSD menu. I tried to set auto record on power up but somehow it wasn't recording menu properly.

Maybe the delay at the end should work like this:

1. Quad disarmed
2. 10 seconds timer starts
3. Timer slowly goes down to zero
4. Whenever there is a change in OSD content (like entering menu) the timer sets again to 10 seconds
5. When you stop touching your radio (effectively OSD content will not be changing) the recording will stop after 10 seconds

It would be even little less than 10 seconds to really give the MSP-OSD the time to properly end recording before you disconnect battery. I guess when you are really doing something in the OSD menu or checking stats you need like 5 seconds between stick inputs.

[j005u]

OSD recording with auto record seems to at best be hit or miss indeed. @Knifa @LouDnl could yall look into this when you have the time?

Can't promise you guys when anyone will take on adding a delay to ending the recording, but I can definitely see the value. I think though that a simple configurable timeout would suffice for most cases. Another thought was to also always dump the last n frames of OSD data received to the SD card (or better yet internal storage, in case you don't have an SD card) on eg. connection loss.

Detecting the OSD state and recording based on that might be dicey due to eg. blinking characters etc. Different FCs have different OSDs. At least I wouldn't do it by default.