Can't create video from manually recorded frames

[EtalumaSupport]

api.log
autofocus.log
camera.log
gui_interactions.log
lumaviewpro.log
lumaviewpro_errors.log
metrics.log
serial.log

[ericweiner]

Likely fixed on 4.0.0-wave7-decomp by the manual-video / record pipeline rewrite landed 2026-05-12 / 05-14. Relevant commits:

• b38bcce fix(wave7): record_init crashed on missed scope.camera rename
• 35f787b feat(record): drive manual record on camera SDK callback, retire Kivy Clock save timer
• af44fe6 fix(record): drive Clock at video_fps instead of exposure_freq
• 153f4e9 feat(record): host-side save-time decimation + per-frame timestamps in filenames
• 1d2dc31 fix(record): stop double-dispatch + clean up memmap scratch file
• c1aedcc fix(record): hoist StackBuilder + VideoWriter imports to module top
• 4dd1057 fix(record): bounds-check record_helper to drop frames past buffer cap

Please retest on the next bench build of 4.0.0-wave7-decomp. The lumaviewpro.log will identify the build via Branch: 4.0.0-wave7-decomp and Built: <timestamp>.

[ericweiner]

The Wave 7 manual-video / record pipeline rewrite is in beta12 (`4.0.0-beta @ f64073c`). Relevant commits: `b38bcce`, `35f787b`, `af44fe6`, `153f4e9`, `1d2dc31`, `c1aedcc`, `4dd1057`.

Test asks:

1. Cold-start LVP. Verify startup banner says `Branch: 4.0.0-beta` and `Built: 2026-05-17 12:02` (or later).
2. Start a manual video record (Live mode, single channel, click Record).
3. Let it run 5-10 seconds, click Stop.
4. Generate video from the recorded frames (the "Build Video from Frames" action you originally hit the bug on).
5. Expected after fix: video generates successfully with no error popup; the resulting MP4 plays cleanly in any viewer.
6. If it still fails, attach `lumaviewpro.log` and the contents of the manual-record folder (TIFF frames + session_manifest.json if present).

If video generation works end-to-end, this can close.

[ericweiner]

Fix shipped -- ready for bench verification

Root cause: The manual-frame video creation pipeline was broken end-to-end -- frame capture didn't correlate to the protocol record, the ffmpeg invocation used the wrong color order, and the output filename collided with stitcher outputs. Seven commits rewrite the record path + the video assembly + the filename generation.

Fix: modules/video_builder.py + ui/post_processing.py + modules/protocol_image_writer.py -- coordinated rewrite of the manual-frame -> video pipeline.

SHA: beta12 cluster -- b38bcce + 35f787b + af44fe6 + 153f4e9 + 1d2dc31 + c1aedcc + 4dd1057 on 4.0.0-beta (current tip 4b972e9, 4.0.0-beta14 build).

Regression test: tests/test_video_builder.py covers the assembly path; tests/test_protocol_overwrite_guard.py covers the filename collision.

Retest signal:

1. Record manual frames during a live session (the camera "record" button).
2. Use Image Processing -> Create Video on the recorded folder.
3. Expected: a valid .mp4 produced, color order correct (not BGR-swapped), filename does not collide with stitch / composite outputs.

EtalumaSupport, please download the latest beta build and verify the fix. Then either close this issue if fully resolved, or add a note describing what is still happening.

[EtalumaSupport]

Still failing, screenshot attached

[SN12064-2026-05-27-081138.zip](https://github.com/user-attachments/files/28313580/SN12064-2026-05-27-081138.zip)

[ericweiner]

can you please try re-attaching the logs? I don't think they ended up getting in there, I can't see them.

[EtalumaSupport]

I see the file in my comment but had to come home for my CMaT meeting, will reattach around 10am

[ericweiner]

no rush, I'm deep into the mono-native conversion right now.

[EtalumaSupport]

SN12064-2026-05-27-081138.zip

[ericweiner]

Fix shipped -- ready for verification (4.0.0-beta @ f1304d56).

Create Video now works on manually recorded ("Frames") folders. Previously the
button only accepted protocol-scan folders (which carry a protocol record file);
a manual recording has no such file, so it was rejected outright.

While fixing this, the timestamp behavior also changed so the "timestamp
overlay" checkbox in Create Video is now respected: recorded frames are saved
without a timestamp drawn into the image, and the timestamp is drawn onto the
generated video only when the checkbox is on. The timestamp still travels in
each frame's metadata and filename, so no timing information is lost. This also
covers the duplicate reports about Create Video on frame-based recordings.

To verify on the bench (next 4.0.0-beta pull/build):

1. Set the video record format to "Frames" and do a manual recording.
2. Post Processing -> Create Video, point it at that recording folder.
3. Confirm a video is produced (no "protocol record not found" error).
4. With the timestamp overlay OFF, confirm the video has no timestamp; with it
   ON, confirm the timestamp appears and advances per frame.

If it checks out, please confirm and close. If anything is still off, just
comment and the label will drop automatically.