Verification, checksums & MHL

A copy is a claim; verification is the proof. This chapter explains exactly what IngestDeck checks, how the checking works mechanically (and why you can trust it), and how the proof is recorded — as per-file results you can browse and as MHL / ASC-MHL manifests other tools read.

The always-on baseline: file size

Every copy verifies file sizes — always, in both modes, whether or not you enable anything. After the copy loop finishes, IngestDeck re-checks every destination file's size against its source. This catches truncated and short writes (the classic "the disk said fine but the file is 3 GB short" failure) at almost zero cost. Results show it as Size verified.

The size check is a floor, not a substitute for checksums: it cannot catch corrupted bytes. That's what checksum verification is for.

Checksum verification: how it actually works

Turn on Verify (Simple's checkbox, a Copy node's Verify add-on, or a standalone Verify node) and IngestDeck runs hash-during-read with destination read-back:

1. Hash the source as it streams

   While the copy reads a file from the card, the same bytes are hashed in-line. No second read of the source — the copy pass and the hash pass are one pass.

2. Read the destination back — from the disk, not the cache

   After a file lands, IngestDeck reads it back with the filesystem cache bypassed (F_NOCACHE). This matters: a cached read would just hand back the bytes from RAM and prove nothing about the disk. The read-back proves what's physically on the destination.

3. Compare

   The destination hash must equal the in-line source hash. Any mismatch marks that file failed and the operation red — with the file name and the hashes in the result.

The read-back is overlapped with the copy: verification of finished files runs while later files are still copying, so on most jobs full verification costs far less wall-clock time than a separate verify pass would.

Algorithms

The hashing engine implements xxHash (xxh64 / xxh3-64), MD5, SHA-1, SHA-256 and C4. In the Verify UI you pick a preset:

When the source carries an existing ASC-MHL history, the picker is constrained to presets that include the algorithms already recorded in the chain — so a continuation never drops an algorithm a previous generation promised (see below).

Three places verification lives

• Simple's Verify toggle — the one-checkbox version; verifies the whole job with the selected algorithm.
• The Verify add-on on a Copy (or Convert) node — fused into the operation, overlapped read-back, and the place to attach an inline MHL report. Convert's add-on is a write-integrity check: each transcoded output is read back and confirmed (there's no source hash to compare a transcode against — the bytes are new by definition).
• The standalone Verify node — a separate scheduled step. Point it at one or more upstream copy results (they verify serially inside the node), or wire it straight to a Source for an audit. Details and connection rules in the node reference.

MHL & ASC-MHL manifests

Verification proves the copy to you; a manifest proves it to everyone else. Enable a Report (on the Verify add-on or the Verify node) and IngestDeck writes a Media Hash List next to the media:

• Legacy MHL — the classic timestamped .mhl XML sidecar many pipelines still expect.
• ASC-MHL — the ASC's modern standard: an ascmhl/ folder of immutable per-generation manifests plus a chain file. Read by Silverstack, DaVinci Resolve and other DIT tools.
• Both — write the two side by side.

Facts worth knowing about how IngestDeck writes them:

• Reports force checksums. Enabling a report coerces full checksum verification on — a manifest without verified hashes would be a lie, so it can't happen.
• Hashes are reused, not recomputed. The manifest is written from the hashes the verification just confirmed; no third read of your media.
• Dataset-scoped and movable. The manifest lands inside the copied dataset folder (e.g. <run folder>/<card name>/ascmhl/) with paths relative to it — move or archive the folder and its proof travels along, self-contained.
• Chain continuation (generation N+1). If the source already carries an ascmhl/ history, IngestDeck carries it to the destination and appends the next generation instead of starting over — the manifest shows an unbroken lineage: camera → card → shuttle → archive. Chain coherence is enforced: algorithms recorded by earlier generations are never dropped from later ones.
• The Source card tells you. When a dragged-in source carries ASC-MHL history, its node card shows a badge — ASC-MHL · N gen — so you can see at a glance that a card arrives with provenance.

Auditing without copying

Wire a Verify node directly to a Source and no bytes are copied at all: IngestDeck finds the source's own ASC-MHL, re-hashes every recorded file with the algorithms the manifest records, and fails red on any mismatch, missing or unreadable file — or if the source carries no manifest. Use it to check an archive disk before trusting it, or to confirm a shuttle that traveled without you. (For comparing two trees that don't have manifests, use Compare.)

Reading the proof

Every verified run keeps per-file receipts: open the result (from the queue, the node, or History) and every file shows its ✓/✗, the reason on failure, and the confirmed hash. Verification state is also a column in the results table, and the whole run stays browsable offline. See Results & media tools.