Data Recovery Case File · Cameras, Drones & Cards · The Files Are Fine
Content That Plays in the Camera Is Intact, So the Failure Is in the Path Out
His enquiry contains an observation that settles the most important question before anything else is examined. A card holding raw video that will not copy across several machines of both platforms, where "files play perfectly fine in camera" and two files eventually copied before the rest froze. Playing in the camera proves the data is readable — so what has failed is the route out, not the recording.
| Media | 128GB high-speed camera card holding raw video — content playing normally in the originating camera; transfers to multiple hosts of both platforms failing after two files |
| Reported situation | High-speed card holding approximately 20GB of raw video · content playing without fault in the originating camera · copying attempted on several machines across both platforms · two files copied successfully · remaining transfers freezing · deadline stated by the owner |
| Fault class | Content readable in the originating device with transfer failing — reader, interface or host handling implicated rather than the card's stored data |
| Equipment used | Playback in the originating device accepted as establishing content integrity · reader and interface eliminated as variables before the card was implicated · card imaged write-blocked at the block level under capped timeouts · marginal regions revisited across later passes · recovered clips validated by playback in full |
The decode: what playback proves, and where the failure actually sits
What playing a clip in the camera requires: the whole file. The camera reads the card, locates the file, and decodes it from beginning to end — which cannot happen if the data is not there or cannot be read.
Why that is the strongest possible evidence: it is a complete read performed successfully. Not a thumbnail, not a preview, but the content itself, and it is being done by a device that reads this card format natively.
What it therefore eliminates: the card's stored data. The files are present, complete and readable, which removes the entire category of concern most people arrive with.
Where the failure must therefore sit: between the card and the computer. The reader, the interface, or the host's handling of a sustained transfer — three candidates, none of them the recording.
Why the reader is the first suspect: high-speed card formats require a reader that supports them properly. A reader that negotiates a slower or incorrect mode reads small files and fails on sustained transfers, which matches two files copying and the rest freezing.
Why trying several computers did not settle it: he may have used the same reader on all of them. Changing the host while keeping the reader changes the wrong variable, and it is the commonest way this test fails to test anything.
Why the file size matters here: raw video files are large and copied in one continuous operation. A marginal interface that survives a small transfer fails partway through a large one, and freezing rather than erroring is what an interrupted read produces.
What is worth trying before anything else, given his deadline: a different reader, ideally one designed for that card format. It costs very little and it addresses the most likely cause.
Why copying through the camera is worth trying too: the camera reads the card successfully and can frequently transfer over its own connection. Using the device that demonstrably works removes the reader entirely.
What must not happen given the pressure of the deadline: no formatting, no repair utilities and no recovery software run against the card. The files are intact, and the fastest route is the one that changes least.
On the bench
Playback in the originating device was accepted as establishing content integrity — playing a clip requiring the whole file to be located and decoded end to end, which cannot occur if data is absent or unreadable, and being performed by a device that reads the format natively. Failure must therefore sit between card and host: the reader, the interface, or handling of a sustained transfer. High-speed formats require proper reader support, a mismatched reader succeeding on small files and failing on large ones. The reader and interface were eliminated before the card was implicated.
The outcome
Playback accepted as establishing content integrity, the reader and interface eliminated before the card was implicated, and the card imaged under capped timeouts. Free assessment, one fixed written figure including VAT; on cards where content has been deleted or overwritten, the figure is payable upfront. The decode: they play in the camera, so the files are fine. That is a complete read done successfully — which moves the whole question to the route between the card and the computer.
Footage that plays in the camera and will not copy
Try a different reader first, ideally one made for that card format — it costs very little and it's the most likely cause, since a reader that negotiates the wrong mode copies small files and fails on sustained transfers. Then try copying through the camera itself over its own connection, which removes the reader entirely and uses the device that demonstrably works. Trying several computers with the same reader changes the wrong variable. And don't format, repair or run recovery software: playback proves the files are intact.
Change the reader, not the computer — call Manchester Data Recovery on 0161 871 0788; playback accepted as establishing content integrity, reader and interface eliminated first, imaged under capped timeouts.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.