Fix multi-segment recording data loss during recovery

[blakesims]

Summary

Fixes #1509 - Multi-segment recordings (from pause/resume) lose middle segments during recovery/remux.

Root Cause: The recovery process sorted segment directories alphabetically, causing segment-10 to come before segment-2. Combined with index assignment from enumeration, this caused wrong segments to be processed/deleted.

Changes:

• Natural numeric sort for segment directories instead of alphabetical
• Parse segment index from folder name instead of using enumeration index
• Use actual segment path from metadata in create_project_config

Test Plan

• Record with 10+ pause/resume cycles (creating segment-0 through segment-9)
• Verify all segments have display.mp4 and camera.mp4 after recording stops
• Verify metadata includes all segments in correct numeric order
• Verify editor plays through all segments without gaps

Before fix: Only segments 0, 1, 10, 11 preserved; segments 2-9 lost
After fix: All segments 0-9 preserved correctly

🤖 Generated with Claude Code

Greptile Summary

Fixed multi-segment recording data loss during recovery caused by alphabetical sorting treating segment-10 as coming before segment-2. The recovery process now uses natural numeric sorting to order segment directories correctly, and parses the segment index directly from folder names (segment-N) instead of relying on enumeration position. Additionally, create_project_config now uses the actual segment path from metadata instead of reconstructing it from the loop index.

Key changes:

• Natural numeric sort for segment directories (lines 139-144)
• Parse segment index from folder name instead of enumerate index (lines 149-153, 200)
• Use actual segment path from metadata in create_project_config (line 913)

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The fix addresses a critical data loss bug with a clean, focused solution. The changes are minimal, well-tested according to the test plan, and directly fix the root cause (alphabetical vs numeric sorting). The natural numeric sort implementation correctly handles edge cases (unparseable names get u32::MAX), and the segment index parsing is straightforward with proper fallback to 0.
• No files require special attention

Important Files Changed

Filename	Overview
crates/recording/src/recovery.rs	Fixed critical data loss bug by implementing natural numeric sorting for segment directories and parsing segment index from folder names instead of enumeration position

Sequence Diagram

sequenceDiagram
    participant FS as File System
    participant RM as RecoveryManager
    participant Sort as Sorting Logic
    participant Proc as Processing Loop
    
    Note over RM: analyze_incomplete()
    RM->>FS: read_dir(segments_dir)
    FS-->>RM: [segment-0, segment-1, ..., segment-10, segment-2]
    
    RM->>Sort: sort_by_key(natural numeric)
    Note over Sort: Parse "segment-N" → u32<br/>segment-10 → 10<br/>segment-2 → 2
    Sort-->>RM: [segment-0, segment-1, segment-2, ..., segment-10]
    
    loop For each segment_entry
        RM->>Proc: Parse index from folder name
        Note over Proc: "segment-2" → index=2<br/>(not enumerate index!)
        Proc->>RM: RecoverableSegment{index: 2, ...}
    end
    
    Note over RM: build_recovered_meta()
    RM->>RM: Use seg.index for segment_base path
    Note over RM: segment_base = "content/segments/segment-{seg.index}"
    
    Note over RM: create_project_config()
    RM->>RM: Use segment.display.path from metadata
    Note over RM: No longer reconstruct from loop index

Loading

[greptile-apps]

Greptile found no issues!

From now on, if a review finishes and we haven't found any issues, we will not post anything, but you can confirm that we reviewed your changes in the status check section.

_{This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR".}

[richiemcilroy]

Thanks for the awesome PR!