Generating captions fails with "Failed to open video file: Is a directory"

[moelkomy]

Description

Generating captions for a recording fails immediately with the following error:

Failed to generate captions: Failed to extract audio from video: Failed to open video file: Is a directory

When Cap tries to extract the audio track from the recording (the first step of caption generation), it attempts to open a path that is a directory rather than the actual video file, so the call fails with "Is a directory" (EISDIR). No audio is extracted and no captions are generated. It looks like the recording's folder path is being passed to the audio-extraction step instead of the path to the video file inside it.

Reproduction

1. Open a recording in the Cap editor
2. Go to the Captions tab
3. Click Generate Captions
4. The operation fails immediately with the error above — no captions are produced

Additional Context

• Cap version: 0.5.2 (0.5.2)
• Operating system, version: Mac OS Tahoe 26.5.1
• Device (optional): Macbook Air M5

[linear]

CAP-743

[tembo]

The bug is in apps/desktop/src-tauri/src/captions.rs at line 217. The extract_audio_from_video function checks if the path ends with .cap to determine whether to treat it as a project directory:

if video_path.ends_with(".cap") {
    // Handle as directory with recording-meta.json
} else {
    // Try to open as a video file directly
}

The problem is that editorInstance.path (passed from apps/desktop/src/routes/editor/CaptionsTab.tsx line 716) is the project directory path, but the directory name doesn't necessarily end with .cap. When the check fails, the code falls through to the else branch at line 482, which tries to open the directory path directly with avformat::input(&video_path), resulting in the "Is a directory" error.

The fix should change the check from a string suffix match to an actual filesystem check:

// Before
if video_path.ends_with(".cap") {

// After  
if std::path::Path::new(video_path).is_dir() {

This would correctly identify project directories regardless of their naming convention.

Related context: Issue #1689 also involves caption generation using the wrong source (original vs edited video length), which stems from similar path/source resolution logic in this area.

[richiemcilroy]

This will be fixed later today in 0.5.3 - cheers!