Skip to content

yt-dlp Merge Fails: "Invalid data found when processing input" (Stale Cache)

Problem

A DASH download (separate video + audio formats) downloads "successfully" but dies at the final merge step:

[download] .../VIDEO.f299.mp4 has already been downloaded
[download] 100% of  91.19MiB
[download] .../VIDEO.f140.m4a has already been downloaded
[download] 100% of 124.36MiB
[Merger] Merging formats into ".../VIDEO.mp4"
ERROR: Postprocessing: Error opening input files: Invalid data found when processing input

The [Merger] line is the tell: both streams downloaded fine, but ffmpeg can't open one of them to mux. The error is not a network or format-availability problem — it's a corrupt input file.

Root cause

yt-dlp reused a stale, truncated intermediate file from a previous interrupted run.

The giveaway is has already been downloaded followed by an instant 100%. yt-dlp saw an existing .f299.mp4 / .f140.m4a on disk and skipped re-downloading it — but that file was left half-written when an earlier run was killed, timed out, or hit a 429 mid-stream. The byte count "matches" enough for yt-dlp's resume logic to trust it, but the file is incomplete, so ffmpeg rejects it with Invalid data found when processing input.

This is common on a Plex/media box where the same URL gets retried after an earlier failure (e.g. a subtitle 429 or a JS-challenge error that aborted the run partway through).

Fix

Force yt-dlp to re-fetch the streams instead of trusting the cached fragments.

Option A — one-shot flags (no manual cleanup):

yt-dlp --no-continue --force-overwrites https://www.youtube.com/watch?v=VIDEO_ID
  • --no-continue — don't resume partial files; start each download from zero.
  • --force-overwrites — ignore the "already been downloaded" shortcut and overwrite existing files.

Option B — delete the stale intermediates, then re-run:

cd /path/to/download/dir
rm -f "VIDEO_TITLE".f*.mp4 "VIDEO_TITLE".f*.m4a "VIDEO_TITLE".*.part "VIDEO_TITLE".*.temp.mp4
yt-dlp https://www.youtube.com/watch?v=VIDEO_ID

The format-code files (.fNNN.mp4, .fNNN.m4a), .part, and .temp.mp4 are all disposable — yt-dlp regenerates them. The merged final .mp4 is the only keeper.

Either approach gives ffmpeg clean, complete inputs and the merge succeeds.

If it still fails after a fresh pull

If a genuinely-fresh download still won't merge, the DASH stream itself may be the problem. Sidestep the merge by grabbing a progressive (pre-muxed) format:

yt-dlp -F https://www.youtube.com/watch?v=VIDEO_ID    # list formats
yt-dlp -f 18  https://www.youtube.com/watch?v=VIDEO_ID # 360p progressive mp4, no merge
yt-dlp -f best https://www.youtube.com/watch?v=VIDEO_ID

A progressive format is a single file with video+audio already combined, so there's no merge step to fail — useful as a quick confirmation that the pipeline (not the source) is the issue.

Real-world example (majorhome, 2026-07-24)

A stream download to /plex/plex/ reported both f299 (video) and f140 (audio) as "already downloaded" with instant 100% completion, then failed at [Merger] with Invalid data found when processing input. An earlier run of the same URL had aborted partway, leaving a truncated .f299.mp4 on disk. Re-running with --force-overwrites pulled both streams clean and the merge completed without error.