OBS Recording Recovery — the nuance that decides whether this answer is useful

You pressed Stop and nothing happened. OBS crashed, power died, or the file that should be 4 GB just sits there and won't open. Before you press Record again and overwrite the folder, you need one answer: is the file still there, and what is the gentlest command that could bring it back? This page gives you that verdict in seconds — locally, without uploading — and explains why the fix works.

The check runs entirely in this tab. Your browser reads a few hundred kilobytes of headers from the start and end of the file and never sends any of it anywhere. You can watch the network tab, or turn off Wi-Fi and run it again. What you get back is not a vague “maybe recoverable” — it is which container OBS actually wrote, whether that container writes its index as it goes or only at the end, how many hours and minutes are still readable from timestamps inside the file, and the exact next step that could turn it back into a playable file.

What the result actually means

We classify five outcomes, and each one shows its evidence.

Healthy — The file opens, duration matches recording length, seeks work, and no warnings appear. You don't need recovery; you need to protect the next recording so you never need this page at 2 a.m.

Playable with warnings — The container opens and plays for minutes then desyncs, drops frames, or stops. Usually one bad cluster or a timestamp gap. The media is intact; the timeline is broken. A timestamp rebuild (-err_detect ignore_err -fflags +genpts -c copy) typically fixes it without re-encoding.

Likely repairable — missing moov — The file exists at a plausible size (say 4.1 GB for 90 minutes at 6 Mbps) but will not open. ffprobe or ffmpeg says moov atom not found. This is the classic MP4/MOV failure: the video and audio packets are contiguous before the crash, but the single index that describes them — the moov atom — was never written because OBS never reached its one-pass write at Stop. The packets are there; the map is not. You need a reference file from the same OBS preset to rebuild the map.

Severely damaged — Header present but no decodable packets, or truncated mid-packet with no viable cluster. Some media may be extractable as raw streams, but not as a single playable file without re-encoding.

No usable media detected — 0 bytes. Nothing was flushed. Check Settings → Output → Recording Path, free space, and whether you recorded to a Downloads folder that iCloud purged or an exFAT stick that disconnected. There is nothing to remux; there is a path to fix.

Every verdict shows why — container, stream counts, duration status, index health, and size sanity — so you can trust the next step. We never say “repairable” without qualification because the kindest thing we can do is stop you from re-encoding a file that only needed a one-line remux. Re-encoding halves quality you can never recover.

How containers decide your fate — and why OBS defaults to MKV

This is the core mechanism most creators learn only after a crash.

MP4 and MOV keep one index — the moov atom — that describes every frame. OBS writes it in a single pass when you press Stop Recording. If OBS crashes, power dies, or the process is killed before that pass, the file holds hours of video that nothing can locate. The atoms before the crash (mdat with media, ftyp, free) are there, but without moov no player can seek. ffmpeg reports moov atom not found and exits. Recovery then requires rebuilding that index, which requires knowing what the index should have said — encoder, resolution, FPS, timebase. That is why you need a reference file from the same preset: 10 seconds of good.mp4 recorded after the crash with identical settings gives Untrunc or Recover_MP4 the template it needs. The flow is: preserve original → make reference → untrunc good.mp4 broken.mp4 → ffmpeg -i recovered.mp4 -c copy fixed.mp4 → verify. No re-encoding; once moov is rebuilt, the rest is a lossless copy.

MKV (Matroska) and fragmented MP4 (fMP4 / CMAF) write differently. MKV writes its index as it goes — SeekHead, Info, Tracks, then a sequence of Cluster elements each with its own timestamps and a Cues index that grows throughout. If you pull power at 3:58 of a 4-hour stream, you lose the last Cluster that was still in the write buffer — typically one minute — and the rest is playable. ffmpeg -i broken.mkv -c copy fixed.mkv rewrites the Cues and you get 3:57 intact, lossless. Fragmented MP4 does the same by fragmenting the moov (moof + mdat pairs) every few seconds; it also edits well in Premiere and streams well, which is why modern OBS offers it as Fragmented MP4 under Output → Recording. FLV and MPEG-TS are similarly append-friendly.

OBS defaults to MKV for this exact reason. Many creators switch to MP4 for “compatibility” and inherit MP4’s fragility without gaining anything — you can always remux MKV to MP4 losslessly after the fact (ffmpeg -i in.mkv -c copy -movflags faststart out.mp4). The compatibility you wanted is one command away; the recoverability you lost may be four hours.

Why file size alone lies. A 60 GB stream and a 60 MB stream show the same header size. The inspector seeks directly to the structures it needs — moov location for MP4, last Cues for MKV — instead of reading the whole file. That is why a 60 GB file probes as fast as a 60 MB one and why size does not predict recoverability. Duration measured from internal timestamps is the truth; size is a hint.

Three real scenarios — not toy numbers

Note for obs recording recovery: The following three scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — they show the shape of real usage but are not measured lab cases with sourced files.

1. Four-hour MKV stream, power died at 3:58, 22 GB, won’t open. You streamed 1080p30 at 6 Mbps + 160 kbps audio → ~2.77 GB/h × 4 = ~11 GB single-canvas, ~22 GB dual-canvas. Explorer shows 22,104,332,032 bytes and VLC shows 00:00. Header probe shows MKV EBML present, Tracks with H.264 and AAC, Cues up to 3:57:42, last Cluster truncated mid-SimpleBlock. Verdict: good chance — one bad cluster. You copy first: cp broken.mkv broken.mkv.bak. Then ffmpeg -i broken.mkv -c copy fixed.mkv. FFmpeg warns Cluster at position X is truncated, skipping and writes 3:57:14 playable. If that still fails, ffmpeg -err_detect ignore_err -i broken.mkv -c copy fixed2.mkv skips the truncated SimpleBlock and recovers 3:57:42. Loss is ~18 seconds to 2 minutes, not four hours, because every previous Cluster’s index was already flushed. Remux is lossless — same video bytes, rewritten index.

2. Ninety-minute MP4 podcast, OBS crashed, 4.1 GB, `moov atom not found`. You recorded 1080p30 interview at 6 Mbps + 2-track AAC 160 kbps → expected ~4.37 GB for 90 min, file is 4.12 GB — plausible. ffprobe -v error prints moov atom not found. Header probe shows ftyp, free, mdat (4.1 GB of media), no moov. Verdict: likely repairable — missing moov, needs reference. You make good.mp4: same OBS profile, 10 seconds, same res/FPS/encoder (x264 medium, 6 Mbps, 48 kHz). Then untrunc good.mp4 broken.mp4 — Untrunc scans mdat for NAL units and ADTS frames, infers SPS/PPS and timebase from good.mp4, and writes recovered.mp4 with rebuilt moov. Then ffmpeg -i recovered.mp4 -c copy fixed.mp4 to move moov to front and validate. ffprobe now shows duration 01:29:42, streams H.264 1920×1080, AAC, bitrate ~6.2 Mbps. Zero quality loss after rebuild; you did not re-encode. If Untrunc is unavailable, Recover_MP4 or untrunc forks do the same; the key is matching preset.

3. Zero-byte file after recording to Downloads. You recorded to ~/Downloads while iCloud Drive’s “Optimize Mac Storage” was on and the drive was at 98% full. macOS reported 30 GB purgeable as “free” until OBS needed 30 GB contiguous — write failed, file handle stayed open, 0 bytes flushed. Verdict: no usable media. No mdat, no Cluster, nothing to remux. The file itself cannot be saved. What can be saved is the next recording: change Settings → Output → Recording Path to ~/Movies/OBS on internal APFS, set Recording Format to MKV or Fragmented MP4, and enable verified segmented upload next time. This is the only case where the answer is not a command but a path.

Deep guide — recording so the next crash costs one minute, not four hours

Choose the container once. For OBS, choose MKV or Fragmented MP4. MKV is the most resilient and most forensic-friendly; fMP4 is equally resilient and edits without remux. If you need MP4 for a client, record MKV and remux after: ffmpeg -i recording.mkv -c copy -movflags faststart recording.mp4 — lossless, moves moov to front for web streaming, same quality. Do not record direct to MP4 for long sessions. That single dropdown decides whether a four-hour stream is a one-line remux or a 10-minute moov rebuild at 1 a.m.

Choose the path carefully. Internal APFS, not ~/Downloads (iCloud purgeable), not a network mount, not an exFAT USB stick with a 4 GB per-file limit. APFS handles sparse and contiguous writes, flushes on close, and does not silently evict your file. Keep 10–15% free — macOS swaps and Spotlight need it, and OBS’s muxer needs headroom to finalize the index. Treat 90% full as full.

Make verification the default. WeaverClip’s macOS helper watches Watching landscape... + Watching vertical... in the log and pairs one-minute segments as they land on disk: .../spool/vertical/%CCYY-%MM-%DD_%hh-%mm-%ss.mkv. As segment N finishes writing, it uploads to R2 while segment N+1 records. Local deletion is queued only after byte-count + MD5 match. Missed segments stay and retry with backoff. The timeline paints verified (green), uploading (amber), buffered (gray), and gap (red). A crash then costs one segment — one minute — and the gap is visible so clip suggestions never cross it. Without verification, “the cloud has it” is a hope; with per-segment verification, it is a guarantee.

Order of operations for repair — never re-encode first. 1) Preserve original: cp broken.mp4 broken.mp4.bak (never work in place). 2) Remux losslessly: ffmpeg -i broken.mkv -c copy fixed.mkv. 3) If desync/stutter, rebuild timestamps: ffmpeg -err_detect ignore_err -fflags +genpts -i in.mp4 -c copy out.mp4. 4) If one stream is dead, extract the survivor: ffmpeg -i in.mp4 -vn -c:a copy audio.m4a or -an -c:v copy video.h264. 5) If MP4 moov is missing, rebuild with reference. 6) Re-encode only if none of the above produce a seekable file. Each step is strictly more destructive; stopping at the gentlest fix preserves quality.

What Premiere and DaVinci need. Premiere dislikes variable frame rate and fragmented moov without faststart. If recovered MKV imports as audio-only or with green frames, rewrap: ffmpeg -r 30 -i fixed.mkv -c copy -movflags faststart prores_ready.mp4 or transcode to ProRes proxy for editing while keeping the original lossless master. That is a workflow choice, not a quality loss of the master.

Troubleshooting — when the command looks right and still fails

• “Invalid data found when processing input” on remux. Input truncated mid-packet. Try ffmpeg -err_detect ignore_err -i broken.mkv -c copy fixed.mkv. If still failing, extract surviving stream: -vn -c:a copy or -an -c:v copy, then rebuild the missing index separately.

• Recovered MP4 has no audio. AAC priming samples missing (encoder delay). Extract video first, then ffmpeg -i video.h264 -i audio.m4a -c copy -movflags faststart out.mp4. The audio stream’s priming is in its own mdat; combining after extraction restores sync.

• Faststart made file slightly bigger. Expected. It relocates moov to the front for streaming and adds faststart metadata. Size delta is moov size (~2–5 MB) — not bloat, not compression.

• Reference rebuild still says moov not found. Reference mismatched: different resolution, FPS, or encoder (e.g., good is 30 FPS, broken is 60 FPS). Record 10 s on the exact OBS profile that created the broken file — same Output → Recording settings — and retry.

• File recovers but seeks are slow. Cues were rebuilt without keyframe index. Remux again: ffmpeg -i recovered.mp4 -c copy -movflags faststart seekable.mp4 forces a new Cues/moov with keyframe table.

1. Premiere imports recovered file as 0:00. Variable timebase. Force constant: ffmpeg -i recovered.mp4 -c:v copy -c:a aac -ar 48000 -r 30 -fflags +genpts constant.mp4 — keeps video lossless, re-encodes only audio to 48 kHz AAC if needed.

Decision guide — what to do in the next 10 minutes

If the verdict is Healthy or Good-chance remux, run the gentlest ffmpeg -c copy on a copy and you are done in seconds — no quality loss, no reference file. That is the best outcome and the most common for MKV.

If the verdict is Likely repairable — missing moov, budget 5–10 minutes: make the 10-second reference on the same preset, run Untrunc, then ffmpeg -c copy to validate. Do not re-encode; once moov is rebuilt, the rest is a lossless copy.

If the verdict is No media, stop. The file cannot be saved. Change the recording path to internal APFS, set format to MKV or fMP4, and enable segmented verification before the next session. The value of this page is not to undelete 0 bytes — no one can — but to make the next crash cheap.

For every other verdict, switch next recording to MKV or fMP4 and enable WeaverClip segments so the next crash is a one-minute recovery, not a four-hour forensic job. That single change moves you from recovery to protection — from hoping a command works to knowing a minute is already verified in R2.

How this connects to WeaverClip — without bullshit

WeaverClip does not promise to undelete 0 bytes. What it does is make the next crash cost one minute, not the file. One-minute segments upload as the next minute records, verified before local delete, gaps painted, clip suggestions gap-aware so you never select a moment that crosses an unverified gap. If this checker just saved a 4-hour stream with a one-line remux, the permanent fix is to record the next stream through that verified path so you never need the checker at that hour again.

FAQ — answers people come back for

Does this upload my file? No. The checker reads a few hundred KB of headers locally and never sends them. You can disconnect Wi-Fi and run it again to confirm.

MP4 vs MKV for recovery? MKV or fMP4 writes its index as it goes; MP4 writes one moov at Stop. For crash safety, choose MKV/fMP4. You can remux to MP4 losslessly after.

How exact is ‘likely repairable’? We show evidence: container, streams, duration status, index health, size. No evidence, no claim.

Will re-encoding fix it? Last resort only. Re-encoding halves quality a remux would have kept.

What about 0 bytes? Nothing to recover. Fix the path and enable verification before next record.

When should I re-check? After any crash, before you record over the folder, and before you change container or path for the next session.

Appendix — second-order effects most pages never mention

Muxing overhead is 1–2% but decides whether 90% full is truly 90%. On APFS with clones and Time Machine snapshots, Finder’s “free” is optimistic until you need 60 GB contiguous for a 10-hour VOD. Habit is the biggest variable: you check once, then toggle 60 FPS for gaming and forget to re-check — that one toggle adds 50% file size silently. We put a ‘what if’ row under every result so you feel the delta before you press Record.

For segmented recording, the nuance is per-segment ordering: segment 1 verified → delete 1, then segment 2. Interrupted network does not leave you with ‘maybe the cloud has it’. The rail shows verified / uploading / buffered / gap, and clip scoring refuses to suggest a moment that crosses a gap. For transcript discovery, the nuance is speaker labels and timestamps: without HOST:/GUEST: the scorer loses “unexpected admission” signals; without timestamps it cannot tell whether 12 suggestions are distinct stories or one story rephrased.

For repair, never re-encode first. Copy → remux → timestamp rebuild → stream extract → moov rebuild → re-encode. Each step is more destructive; stopping at the gentlest fix preserves quality. For captions/chapters, reading speed decides: a 7-second caption with 18 words reads; a 2.8-second caption with 18 words flashes. YouTube requires 3+ chapters, first at 00:00, each ≥10s, or it ignores them. Those are hard gates, not suggestions. Every result here shows its formula, assumptions, exactness, and what changes it.

The first 60 seconds after a crash — what to touch and what not to touch

The most expensive mistake is not the crash. It is what you do in the next minute. Do not press Record again into the same folder with the same filename. OBS will happily overwrite or create a new file with a suffix, but the filesystem may reuse the same blocks, and a remux that is still possible becomes impossible after a second write. Do not close the file manager preview that is holding the file handle. Do not run a “repair my video” app that re-encodes to “fix” it — that app will read the broken index, fail, and write a new file with the same broken index plus a re-encode pass that halves quality.

Do this instead, in order: 1) Leave OBS open if it is still open; it may still hold the handle and its log tells you the exact path and container. Screenshot the log line Recording... if you can. 2) Open Finder → Go → Go to Folder → paste the Recording Path and confirm the file exists, its size, and its extension. Is it 0 bytes or gigabytes? 3) Copy. In Terminal: cp "broken.mkv" "broken.mkv.bak" or duplicate in Finder. Work only on the copy from now on. 4) Run the checker on this page with the copy — not the original — to get the container-specific command. 5) Decide: MKV → remux; MP4 0 bytes → change path and protect next recording; MP4 with size but no moov → reference rebuild. This sequence takes 60 seconds and preserves every option.

What professionals keep ready before they ever crash: a 10-second reference file (same OBS profile) sitting in ~/Movies/OBS/_reference/ so moov rebuild is a one-line command, a second drive or R2 bucket with 20 GB headroom, and a helper that verifies segments so the next crash is already handled. That preparation is why a four-hour stream can be a shrug instead of a crisis.