The hash of an asset does not agree with the PKL
One byte of that file is different from the byte the packager saw. The package is not playable as it stands.
The message you saw
The hash (...) of the picture asset ... does not agree with the PKL file (...).The hash (...) of the sound asset ... does not agree with the PKL file (...).The PKL and CPL hashes disagree for picture asset ...The first two are INCORRECT_PICTURE_HASH and INCORRECT_SOUND_HASH in libdcp. The third is MISMATCHED_PICTURE_HASHES, a different condition: there the file matches the packing list but the packing list and the composition disagree with each other. Note the Player says disagree where the command line says differ.
What the packing list is asserting
When a DCP is created, the packager computes a SHA-1 digest of every asset and writes it into the packing list as base64. That digest is a claim: this exact sequence of bytes is what I packaged. A verifier recomputes the digest and compares.
Because SHA-1 covers the whole file, a single altered byte anywhere in a 40 GB reel produces a completely different digest. The error tells you the file changed. It cannot tell you where, or by how much.
What actually causes it
Interrupted or resumed transfers are the leading cause. A copy that stalls and restarts can leave a file that is the right length but wrong in the middle, which is why a size check alone passes and the hash check fails.
Cloud sync is the modern culprit. Dropbox, Google Drive, and iCloud may place a placeholder, re-encode, or write extended attributes into a file. A DCP that round-trips through a synced folder frequently fails hashing while looking untouched.
Well-meaning edits also do it. Renaming an MXF is safe; opening one in a tool that rewrites headers is not. So is unzipping with an archiver that normalises line endings, which corrupts XML assets while leaving MXFs alone.
Fixing it, in the right order
Re-copy the failing asset from wherever the DCP was originally written, then verify again. Most hash failures are transfer damage. The master is usually fine.
If the source copy fails too, the damage predates delivery and the asset has to be re-exported from the timeline. Re-export only when the source genuinely fails, because a fresh export produces new UUIDs and new hashes, which invalidates any KDM already issued against the old composition.
Copy DCPs with a tool that verifies, such as rsync -c or a checksum-aware copier, rather than a desktop drag. On a package this size, an unverified copy is a coin flip you take once per asset.