Damaged and Incomplete Media Files
A damaged media file can lose container structure, timing, or encoded content, with different consequences for recovery.
A recorder stops unexpectedly after writing several gigabytes. The size proves that bytes were written, but leaves a more useful question open: which information had been written when it stopped?
A player needs descriptions of the media, a way to locate and time it, and the encoded content itself. Damage to these parts produces different failure patterns.
| Observation | A possible missing part |
|---|---|
| Reader cannot initialize the file | Essential track setup or sample descriptions |
| Opening plays, but jumps take a long time | Useful navigation entries |
| Repeated failure at one scene | Encoded packets or structure around that location |
| Apparent duration exceeds actual playback | Final media data is absent although earlier descriptions remain |
The observations identify which stage to investigate; they do not uniquely name a fault.
An unfinished conventional MP4
A writer can accumulate media in mdat and finish the moov description later. If interruption leaves no usable moov, the reader may lack codec setup, sample sizes, locations, or timing needed to interpret the existing data. There can be abundant payload without an ordinary file reader being able to separate it into the right samples.
A routine remux needs a reader to supply usable streams first. It cannot simply invent the missing descriptions. Specialized recovery can sometimes use information from the recording setup or another matching file, but the reliability depends on the exact source and writer.
Complete earlier groups can survive
A fragmented MP4 with usable initialization and complete earlier fragment descriptions can leave those earlier groups interpretable after an interruption. The last partial group may still be unusable. A transport recording or suitable Matroska writing arrangement likewise distributes information differently from a final-table-dependent file.
This is a structural reason for differing recovery behaviour. The extension alone does not specify when the particular recorder committed its essential information.
Navigation damage and media damage have different limits
If a reader can scan intact streams and timing, a new mux can write indexes that were missing or broken. That can repair navigation without changing the encoded movie.
If some media bytes are absent or corrupted, a decoder may stop, conceal errors, or recover at a later usable point. Rebuilding an index does not restore the original picture or sound for that gap. A checksum can detect an inconsistency where provided; it does not supply a replacement payload.
For a failing Emby item, separate storage access from media interpretation first. A server that cannot read a path has not yet tested the container. If the bytes are accessible, compare initialization results with probing and decoding near the repeatable failure. Unsupported decoding can also fail on an intact file, so the codec and failure stage belong in the evidence.
A repair should be evaluated by what it recovered: track setup, full expected duration, the affected scene, and normal seeking. This is more informative than observing that the repaired output now has a recognized extension.