[iwillwin-wcy]

What

A resume that fails after it has allocated the segment directory leaves an empty segment-N directory behind. That empty directory then makes recovery reject the entire recording:

Incomplete Recording — Recovery validation failed; original recording preserved: Unrecoverable display segment 2

The segments that do hold footage are complete and intact. One empty directory costs the whole recording.

Why

SegmentPipelineFactory::create_next allocates the segment directory, then can fail while resolving the capture target:

INFO  segment{index=2}: cap_d3d_adapter: Selected DXGI adapter ...
WARN  Studio resume failed; retaining paused recording
      error=target_display_crop: Display not found

That path returns the error without removing the directory it just created. discard_resume_pipeline, which does clean up, is only reached from the Linux cancel_resume path.

Recovery then contradicts itself. analyze_incomplete deliberately skips a segment that has no display fragments:

if display_fragments.is_empty() {
    debug!("No display fragments found for segment {}", index);
    continue;
}

but require_recoverable_tracks walked the same directory listing and rejected any index the collector had not collected:

&& !indexes.contains(&index)

So the very segment the collector had just skipped became the reason to abandon everything.

Fix

• Extract segment_display_fragments and call it from both collection and validation, so the two can no longer drift apart about which segments are recoverable.
• Validation ignores an orphan directory only when it holds no recoverable display media.
• A directory that does hold footage but was not collected stays fatal, because recovering around it would silently drop that footage from the recording.

Tests

Two regression tests in crates/recording/src/recovery.rs:

• empty_orphan_segment_directory_does_not_block_recovery — reproduces the real layout (one segment with encoded fragments plus an empty segment-1) and asserts require_recoverable_tracks succeeds. Fails with Unrecoverable display segment 1 before this change.
• segment_directory_with_footage_outside_the_recoverable_set_is_still_fatal — pins the guard so the fix stays narrow.

Context

This came out of a real 8m48s recording that was given up for lost: the user paused, minimized the captured window, hit resume, got Display not found, then pressed stop and the whole recording was written off. The footage was complete on disk — 23791 frames — with only this empty directory standing in the way.

Worth fixing rather than just documenting because the trigger is easy to hit in normal use: is_window_valid_for_enumeration filters out any window where IsIconic is true, so minimizing the captured window during a pause is enough.

Verification

rustfmt --edition 2024 --check passes on the changed file. I could not run the tests locally — my machine has no FFmpeg/vcpkg toolchain, so CI is the first compile. Flagging it so a CI failure isn't a surprise.

Confidence Score: 5/5

The PR appears safe to merge; both previous findings are addressed and no new blocking issue was found.

Summary

Recovery now ignores orphan segment directories that contain no recoverable media.

• Recovery ignores empty orphan folders but keeps folders with footage in the check.

Both previous findings are addressed. Tests were not run during this review.

_{Reviews (3) · Last reviewed commit: "test(recording): recover a recording pas..." · Reviewed by Greptile}

[richiemcilroy]

Thanks for the detailed write-up, this is a real bug. Before review we need Greptile at 5/5 and green CI. Please only skip a segment directory when it holds no recoverable media at all (not just no display), fix the guard test so it actually reaches the populated-directory check, then request a Greptile re-review.

[iwillwin-wcy]

@greptileai

Both P1s are addressed in 615e467:

Skip condition widened to every track. segment_display_fragments grew into segment_track_fragments(segment_path, track, single_file), which the camera arm of segment collection now shares too, and segment_holds_recoverable_media composes it with the audio probe. A segment directory is skipped only when it holds no recoverable media of any kind — one holding only microphone, system-audio or camera media stays fatal, because skipping it would leave that footage out of the published metadata.

Guard test now reaches the guard. It declared two segments in metadata and then dropped segment 1 from the recoverable set, so validation returned Missing display segment 1 before ever reaching the directory-level check, and the assertion could not pass. It now declares a single segment. Added a companion test (segment_directory_holding_only_non_display_media_is_still_fatal) covering the widened condition with a camera-only directory.

[richiemcilroy]

@iwillwin-wcy thanks for the follow-up, the widened "no recoverable media of any kind" check is exactly what we wanted. This now conflicts with main in crates/recording/src/recovery.rs: the segment collection on main uses find_studio_fragments_with_init (with the display.mp4 / camera.mp4 single-file fallbacks) and respawn_directories was reworked, so segment_track_fragments (recovery.rs:610 on your branch) needs to be rebuilt on top of find_studio_fragments_with_init rather than find_complete_fragments_with_init. Could you rebase onto main, keep main's behaviour for the display and camera collection, re-run the three new tests and resolve the two Greptile threads once done? Then we'll run the recovery suites on it.

[richiemcilroy]

@greptileai review

[vercel]

@richiemcilroy is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[richiemcilroy]

Verified for 0.6.2: Greptile 5/5 on this head, full CI green, and the full test suites pass on macOS with this PR combined with the other 0.6.2 changes.