tonhowtf/omniget · error

{}

Error message

{}

What it means

Raised when the final ffmpeg render pass in restore_one exits with non-zero status (video_restore.rs:224). The message is the raw trimmed ffmpeg stderr with no prefix. The transform file's temp directory is cleaned up first, then the error propagates. This means ffmpeg ran but failed during stabilization/encode.

Solutions

  1. Read the embedded ffmpeg stderr — it pinpoints encode, I/O, or filter failures.
  2. Check free disk space at the output location and ensure the output path is writable.
  3. Verify the encoder exists (`ffmpeg -encoders | grep 264` or your target codec) and install a full ffmpeg build.
  4. Re-run the restore so detection regenerates a fresh .trf file.

Example fix

// before: bare stderr
return Err(anyhow!("{}", String::from_utf8_lossy(&out.stderr).trim()));
// after: context helps callers
return Err(anyhow!("falha ao estabilizar '{}': {}", input.display(), String::from_utf8_lossy(&out.stderr).trim()));
Defensive patterns

Strategy: validation

Validate before calling

let meta = std::fs::metadata(output.parent().unwrap())?;
let avail = fs4::available_space(output.parent().unwrap())?;
if avail < estimated_output_size {
    return Err(anyhow!("espaço insuficiente em disco para a saída"));
}

Try / catch

match restore_one(input).await {
    Err(e) => {
        let detail = e.to_string();
        if detail.contains("No space left") { eprintln!("libere espaço em disco e tente de novo"); }
        else if detail.contains("Unknown encoder") { eprintln!("instale um ffmpeg com o codec necessário"); }
        else { eprintln!("falha no render: {detail}"); }
    }
    Ok(item) => item,
}

Prevention

When it happens

Trigger: Second ffmpeg pass (using the .trf transforms file produced by detection) exits non-zero: disk full while writing output, unreadable .trf file, codec/encoder unavailable, or output path not writable.

Common situations: Insufficient disk space for a large re-encode; output directory lacking write permission; ffmpeg build lacking the target encoder (e.g., libx264); trf file deleted by a concurrent cleanup.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors

AI-assisted analysis of tonhowtf/omniget@8600b91f42 (2026-09-12). Data as JSON: /api/errors/ca75425b2520e9e9. Report an issue: GitHub.

Appendix: source

Thrown at src-tauri/omniget-core/src/core/tools/video_restore.rs:224

            &opts.preset,
            "-crf",
            &opts.crf.clamp(10, 40).to_string(),
            "-c:a",
            "copy",
            "-movflags",
            "+faststart",
        ])
        .arg(&output)
        .output()
        .await
        .map_err(|e| anyhow!("ffmpeg nao iniciou: {}", e))?;
    if let Some(file) = trf.as_ref() {
        if let Some(dir) = file.parent() {
            let _ = std::fs::remove_dir_all(dir);
        }
    }
    if !out.status.success() {
        return Err(anyhow!("{}", String::from_utf8_lossy(&out.stderr).trim()));
    }

    Ok(RestoreItem {
        input: input.to_string(),
        output: Some(output.to_string_lossy().to_string()),
        filter,
        bytes_before,
        bytes_after: std::fs::metadata(&output).map(|m| m.len()).unwrap_or(0),
        stabilized: opts.stabilize,
        ok: true,
        error: None,
    })
}

pub async fn run(
    opts: RestoreOptions,
    progress: super::ProgressFn,
) -> anyhow::Result<RestoreResult> {

View on GitHub (pinned to 8600b91f42)