Data Recovery Case File · Desktop Externals & Aging Drives · Two Layers of Loss
An Editing Project Fails When Its Footage Does, Because It Only Holds Pointers
His enquiry describes two symptoms that are really one. A 4TB drive that has become "very slow to open things, and then most things I open are corrupt" — with video footage that refuses to play and editing projects that will not open. A project file contains references rather than footage, so a project failing to open may be reporting the state of the media it points at rather than its own.
| Media | 4TB drive holding video footage and associated editing project files — progressive access latency with files opening as corrupt |
| Reported situation | Drive becoming very slow to open content · most files opening as corrupt · video footage refusing to play · editing project files failing to open · substantial video work held · recovery sought |
| Fault class | Progressive read failure across a media volume — latency indicating retry behaviour; project files dependent on the readability of referenced media |
| Equipment used | Project failures assessed as dependent on referenced media rather than as separate corruption · no further host access permitted · imaged write-blocked under strict per-sector timeouts with readable regions taken first · project files and referenced media recovered together and reconciled · footage validated by playback in full |
The decode: what an editing project actually contains
What a project file holds: decisions rather than content. It records which clips are used, where they sit on a timeline, what was trimmed and what effects were applied — a set of instructions referring to files elsewhere.
What it does not hold: the footage. Video remains in its own files and the project points at them by location, which is why a project file is small and a video library is not.
Why that makes a project fragile in a specific way: it depends on everything it references. A project opening requires the application to locate and read the media it names, and a clip it cannot read stops the process.
Why his two symptoms are therefore probably one: the footage failing is sufficient to explain the projects failing. The project files themselves may be perfectly intact and simply unable to assemble what they describe.
Why that matters for the recovery: project files are small and recover easily. Recovering them without their media returns the decisions and none of the material, which is of limited use.
What the deliverable should therefore be: both, reconciled. Projects recovered alongside the specific clips they reference, with the folder arrangement preserved so the references resolve when they are opened again.
Why the folder structure matters more here than usual: references are stored as paths. Media recovered into a different arrangement will not be found by the project even when every file is present, which turns a complete recovery into a manual relinking exercise.
What the slowness reports independently: the drive retrying. Reads that fail are attempted again with pauses between, and latency measured in that way is a hardware symptom rather than a performance one.
Why video is favourable to recover despite the size: clips are large and written in long continuous runs, and they carry recognisable openings. They are located directly in the raw content where directories fail.
What must not happen: no further attempts to open projects or play footage. Each attempt reads across large regions of a drive that is already failing to complete reads, and the application will retry on his behalf without asking.
On the bench
Project failures were assessed as dependent on referenced media rather than as separate corruption — project files recording clip selections, timeline positions, trims and effects as instructions referring to media held elsewhere, so opening one requires the application to locate and read every referenced file. Latency indicates retry behaviour rather than performance. Projects and referenced media were recovered together and reconciled, references being stored as paths that fail to resolve if the arrangement changes.
The outcome
Project failures assessed as media-dependent, readable regions captured first under capped timeouts, and projects recovered alongside the clips they reference. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: your projects may be intact. They hold decisions rather than footage, and they point at media by location — so a project that will not open is often reporting the footage rather than itself.
When editing projects stop opening alongside the footage
Stop trying to open them, because each attempt makes the application read across large regions of a drive already failing to complete reads. Understand that the two symptoms are probably one: a project file holds clip selections, timeline positions and effects as instructions pointing at media stored elsewhere, so it can be perfectly intact and still fail to open because a clip it references can't be read. Ask for projects and their referenced media to be recovered together with the folder structure preserved, since references are stored as paths.
Stop opening them — call Manchester Data Recovery on 0161 871 0788; project failures assessed as media-dependent, imaged under capped timeouts, projects and referenced clips recovered together and reconciled.
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.