Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Add delay to recording stop after disarming. #52

Open
jaroszmm opened this issue Jan 11, 2023 · 5 comments
Open

Feature request: Add delay to recording stop after disarming. #52

jaroszmm opened this issue Jan 11, 2023 · 5 comments

Comments

@jaroszmm
Copy link

I'm using WTFOS happily on all three systems - INAV, BF, AP and I was wondering if it would be possible to add a small delay between vtx/goggles recieving the 'disarmed' message and actually stopping recording. I don't know, maybe something like adjustable 2-10 seconds delay? This way it would be better to have the OSD stats screens recorded as for the moment it ends up in only a couple of frames of recording, in case of INAV it actually records the first page of stats only.

@delfer
Copy link

delfer commented Apr 11, 2023

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

@robertrypula
Copy link

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
Copy link
Contributor

j005u commented Apr 11, 2023

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.

@LouDnl
Copy link
Collaborator

LouDnl commented Apr 12, 2023

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
Copy link
Contributor

j005u commented Apr 12, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants