Isaac Connor 154786d31d fix: derive event start from mp4 end time in recover_timestamps ...

The mp4 is written as the event records, so its mtime is when recording
finished, not when it started. Set EndDateTime to the mtime and
StartDateTime to duration seconds before it, so Length agrees with
EndDateTime - StartDateTime.

The directory mtime fallback also ran unconditionally after both
branches, overwriting the times just computed and the Deep-scheme
path-derived start. Only use it when there are neither capture jpgs nor
an mp4.

Adds t/event_recover_timestamps.t, which builds a 3 second mp4 with
ffmpeg and checks the recovered times against its mtime.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BV1gDc9T6D6H8gtTcxwLvk

2026-07-21 12:11:37 -04:00

..

dahua_rpc_auth.t

feat: add Dahua/Amcrest RPC PTZ control module with per-model Controls refs #120

2026-06-03 18:00:00 -04:00

dahua_rpc_config.t

feat: add status-aware Light control capability and control-command response path refs #4869

2026-06-03 19:00:00 -04:00

dahua_rpc_light.t

feat: add status-aware Light control capability and control-command response path refs #4869

2026-06-03 19:00:00 -04:00

event_recover_timestamps.t

fix: derive event start from mp4 end time in recover_timestamps

2026-07-21 12:11:37 -04:00

hikvision_light.t

feat: add white-light (CanLight) control to HikVision/LTS module refs #4895

2026-06-09 19:59:10 -05:00