Your recording app crashed mid-take. Is the video recoverable?
Sometimes — and it comes down to one decision the app made before you ever pressed record: whether it wrote the file in fragments as it went, or held the index in memory until you pressed stop.
The short answer: often yes, and it depends on something you cannot see from the outside. Recorders fall into two groups. One writes the file so that it stays playable at every moment. The other assembles the file when you press stop. If your app is in the second group and it died before you pressed stop, the recording is very probably unrecoverable — and the bytes are still sitting on the disk, which is the part people find hardest to accept.
This post is what we learned building crash recovery into a teleprompter, including the numbers off the device we tested it on. If you are mid-panic, skip to what to try right now.
Why a file with data in it can still be unplayable
An MP4 is not a stream of pictures. It is pictures plus a table of contents —
an index called the moov atom that records where every frame starts, how long
it runs, and how audio lines up against it. Without that table a player has a bag of bytes
and no way to interpret them.
The cheapest way to write that table is at the end, once you know what went into the file. That is what a lot of recorders do, and while you are recording it means the index exists only in memory. Kill the process and the memory goes with it. What is left on disk is a file of the right size with no table of contents, which every player on every platform reports as zero seconds long.
The alternative is fragmented writing: flush a small index every few seconds alongside the video. The file is then a chain of self-describing chunks, each one playable on its own. Kill the process and you lose whatever was in flight since the last flush — a couple of seconds — and everything before it plays.
Tested, not inferred
We checked this rather than trusting the documentation, because our own codebase carried a comment asserting the opposite. The test writes a real file, snapshots it mid-write, and never finishes it — which is the state a killed process actually leaves behind. Fragmented: playable. Unfragmented: zero duration, the whole take unreadable.
Truncating a finished file proves nothing, which is the trap here. The writer consolidates everything on close, so a file that has been closed properly and then chopped behaves nothing like a file that was never closed.
What the two platforms do by default
This is the part worth knowing before you trust a long take to any app, because the defaults differ and neither platform advertises it.
| Platform | What the system does | What it means for a killed take |
|---|---|---|
| iOS | AVCaptureMovieFileOutput writes movie fragments, at a default interval of ten seconds. |
Recoverable up to the last fragment. You lose up to ten seconds, not the take. |
| Android | CameraX’s default muxer reports isInterruptionResilient() = false and writes the index on stop. |
A killed take really is lost, unless the app swapped the muxer out deliberately. |
So on iOS the platform is already on your side and most apps inherit that without doing anything. On Android the default goes the other way, and getting the resilient behaviour takes a deliberate change to a muxer factory that CameraX marks as internal. That is a decision an app either made or did not, and nothing in a store listing tells you which.
The failure that looks identical to a lost take
Here is the one we did not expect, and it is the reason this post exists.
Fragmented writing means a surviving file. It does not mean a reachable file. An app keeps its own list of your takes — a database row or a JSON entry — and that entry is normally written when the recording finishes cleanly. Crash, and you get the opposite pairing from the one everybody worries about: the video is on disk and perfectly playable, and the app has no record that it exists. It never appears in the library. There is no button that reaches it. From where you are sitting, that is indistinguishable from the file having been destroyed.
We found two of these on a test device, left over from an earlier build, neither of them constructed for the test:
- 34.7 MB, 13.0 seconds, playable, invisible.
- 36.7 MB, 14.0 seconds, playable, invisible.
Both were adopted into the library on the first launch of a build that knew to go looking. The bytes were never the problem. The missing record was.
What to try right now
In rough order of how likely they are to work.
- Reopen the app before anything else. Do not reinstall, do not clear storage, and do not delete anything. An app with a recovery path runs it at launch, and reinstalling is the one action that reliably destroys the file you are trying to save.
- Look for a “recovered” entry. Apps that reconcile disk against their own library usually surface the result under a generic name — ours says Recovered take — because the script it belonged to and the settings it used are exactly the context a crash destroys.
- Check your camera roll as well as the app. Many recorders keep takes in private storage until you explicitly save, so a crash can leave a file that was never copied out. Absence from Photos or your gallery does not mean absence from the phone.
-
On Android, check the app’s own files directory if you are
comfortable with
adb. A file with a sensible size and a zero duration is the unfragmented case; a file that plays is the recoverable one. - Try VLC before you conclude it is dead. It is more tolerant of a damaged index than a system player, and it will sometimes play a file the Photos app refuses.
- Ask support, with the file size. If the app has a repair path at all, the size and the reported duration are the two facts that tell them which failure you have.
If the duration is zero
Then the index was never written and the app was in the second group. Third-party repair tools exist and occasionally rebuild an index by scanning for frame boundaries. Results are mixed and we would not promise you anything. It is worth an attempt on a copy of the file — never on the original.
What we measured on a real device
Recovery is easy to claim and awkward to demonstrate, so here is the loop we ran and what
came out of it. The kill is am force-stop — a SIGKILL, with no lifecycle
callbacks at all, which is harsher than swiping the app away from recents and much harsher
than a normal crash.
| Step | Result |
|---|---|
| Recorded | A cycle of about 10 seconds, including a 3-second countdown |
| On disk after the kill | 20.9 MB, and no entry in the app’s own library file |
| After relaunch | Adopted as a recovered take, 8.0 seconds, playable |
Two seconds short of the wall-clock cycle, which is what “you lose the fragment in flight” looks like in practice rather than in theory. We set our fragment interval to two seconds for that reason: the platform default of ten narrows nothing, and two seconds is a sentence.
A crash is not the only way a take dies
Worth saying, because fragmented writing does not address any of these and they are more common than crashes:
- Running out of storage. A writer that runs out mid-fragment leaves junk. The fix is to stop the take deliberately while there is still headroom — we re-check every five seconds and stop with twenty seconds of space left — because a take you close is a take you keep. Stopping early costs the tail; not stopping costs the file.
- Heat. Sustained 4K recording throttles phones. A throttled take beats one that stops mid-sentence, so a warning is the right response to a warm phone and ending the take is not, until it is genuinely critical.
- Interruptions. A phone call, another app taking the camera, or the app being backgrounded all end a recording. The file is usually fine; what goes missing is the library entry, exactly as in a crash. This was the bug we shipped and then fixed: takes that ended without anyone asking arrived nowhere, and turned up at the next launch as an anonymous recovered file instead of a named take.
Backgrounding mid-take on the same OnePlus now produces a library entry immediately — 8.2 seconds, titled with the script rather than with a placeholder.
How to not be here again
Before you trust a long or unrepeatable take to any recorder, spend four minutes finding out what it does when it dies. You can test this yourself without any tools, and we wrote the procedure up separately: does a teleprompter app save your video if it crashes?
For anything genuinely unrepeatable — an interview, a client shoot, a one-take performance — record a backup on a second device. No software guarantee is worth as much as a second sensor pointed at the same thing.
Orate keeps the take, then tells you it did
The prompter and crash-safe recording are free, with no account and no watermark. Takes that end without anyone asking for it — a crash, a phone call, another app grabbing the camera — are adopted at the next launch and named after the script they came from.
See how Orate works