Somebody sets an old phone recording overnight. In the morning there is a file, the file is 2.3 GB, and nothing will open it. VLC shows a black frame. The gallery skips it. The phone's own player says the format is not supported.
The instinct at that point is to delete it and try again with different settings. That is usually the wrong move, and it is worth knowing why before you touch anything.
A companion piece here went through the mechanism in detail: why an interrupted Android recording won't play — the short version is that an MP4 keeps its video in one box (mdat) and its index in another (moov), and the index is normally written last, when recording stops cleanly. Interrupt the recording and you keep the video and lose the map to it.
This piece is the other half: what to actually do, in order, when you are the person holding the file.
Step 0: stop recording on that phone
Before anything else, stop the camera app and stop using the device as a camera until you have the file off it. Continuing to record can allocate over freed blocks, and if the file turned out to be zero bytes, whatever is recoverable is on a clock.
This is the step people skip, because the natural reaction to a failed recording is to immediately start another one.
Step 1: read the file size, because it tells you which problem you have
Three outcomes, three different situations:
Large (hundreds of MB to several GB). The frames are there. You have an index problem, and index problems are the recoverable kind. Continue to step 2.
Zero bytes, or a few KB. The recording never got past setup, or the write target rejected it. Nothing to recover; this is a configuration problem, not a data-loss problem. Skip to the prevention section.
Missing entirely, but the app said it was recording. Most often the file exists somewhere you are not looking. Android's scoped storage means an app can write into its own private directory, into a MediaStore entry that is still flagged pending, or into a location a file manager does not index. A file that never had its pending flag cleared is invisible to the gallery and perfectly intact on disk.
Step 2: try a player that does not trust the index
Before concluding anything, open the file in a player that will attempt playback without a complete header. VLC and mpv will both try. Some builds will play a headerless file straight through, or play it with a wrong duration and no seek bar.
If it plays at all, do not celebrate and move on — a player being forgiving is not the same as the file being fixed. Go to step 4 and rebuild it properly, because the next tool in your chain will not be as forgiving.
Step 3: copy it off the phone first, and work on the copy
Pull the file to a computer over USB or over your own network, verify the copy is the same size as the original, and then leave the original alone until you are finished.
Every repair tool works by writing a new file. Doing that on the source device, on the storage that just failed you, on a card that may be the actual culprit, is how a recoverable file becomes an unrecoverable one.
Step 4: rebuild the index from a known-good reference
This is the part most people do not know exists.
A repair tool cannot invent an index out of nothing, but it does not have to. If you record a short clip on the same phone, same app, same resolution and framerate, that clip contains a complete, correct moov box describing exactly the encoder settings your broken file was written with. The tool reads the structure from the reference and applies it to the orphaned mdat.
That is what untrunc does, and it is why its first argument is a working file and its second is the broken one. It is also why the reference has to match: a 1080p30 reference will not correctly describe a 4K60 body.
Two practical notes. First, output is usually a new file next to the input, so check for it rather than assuming the tool did nothing. Second, expect to lose the tail — the last few seconds after the last complete frame boundary are genuinely gone, not hidden.
If you would rather not build a tool from source, ffmpeg can sometimes remux a partially-readable file into a fresh container (-c copy into a new MP4 or MKV) and salvage what it can parse. It is a lower success rate than a reference-based rebuild, but it takes thirty seconds to try.
Step 5: work out which failure you actually had
Recovery without diagnosis just buys you a repeat. The realistic causes, roughly in order of how often they turn out to be the answer:
- The app was killed while recording. Battery optimisation, a low-memory kill, or an OS update reboot. The recording ended without the stop path ever running.
- Storage filled. Writes started failing partway through the night. The file size will often be suspiciously round.
- The card was the problem. A removable card under sustained write load can fail without reporting an error — worth reading about separately, because it is the failure that looks least like a failure.
- The file went to a location that was cleared. App-private directories get wiped on uninstall and on some "clear data" actions.
Prevention, which is cheaper than any of the above
Prefer segmented recording where you have the option. A camera setup that closes and reopens a file every few minutes finalises an index every few minutes. An interruption then costs you one segment instead of one night. This is the single highest-value change available, and it is the reason continuous-recording surveillance gear has worked in segments for decades.
Stop the recording deliberately. Not by force-closing the app, not by letting the battery die. The clean-stop path is what writes the index.
Verify once, early. After you set the phone up, record for ten minutes, stop, and confirm the file plays on a different device. Ten minutes of verification is worth more than nine hours of untested confidence.
Check that something is actually running, on a schedule. The failure mode that quietly ruins these setups is not a corrupt file — it is an empty folder that nobody looked in for three weeks.
Watch it live rather than trusting it blindly. If you can open a live view from another device on your own network, "is this thing still recording" stops being a question you answer in the morning.
The honest limitation
None of this makes a phone camera as robust as purpose-built recording hardware with a battery-backed controller and journalled storage. It makes it recoverable, which is a lower bar and a more useful one for a device that cost you nothing because it was already in a drawer.
And there is a bar underneath even that: a recovery you can perform is worth more than reliability you were promised. Every one of the steps above is something you can do yourself, with the file in your own hands, without an account or a support ticket.
Background Camera RemoteStream is a free Android app that records with the screen off and streams live to another device over your own network — no account required. More at superfunicular.com.
Top comments (0)