File size on disk disagrees with the packing list
The packing list records a byte count for every asset. This one disagrees, which means the file is incomplete or has been altered.
The message you saw
"..." is 41,203,712 bytes on disk but the PKL says 41,988,096. The file is truncated or was modified after packaging.Reported by our browser check as code size-mismatch. DCP-o-matic reaches the same conclusion through hash verification, which is slower but also catches files that are the right length and wrong inside.
Why size is checked before hashes
Reading a byte count costs nothing. Hashing a 40 GB reel costs minutes of disk throughput. Checking sizes first means an obviously truncated package fails in a second rather than after a long wait.
A size mismatch also has a narrower set of causes than a hash mismatch, so it points more directly at what happened.
What a wrong length means
Short files are interrupted copies. The transfer stopped, and what landed is a prefix of the real asset. This is the overwhelmingly common case.
Files that are longer than declared are rarer and more interesting. Something appended to them, which on macOS often means resource-fork metadata written by an archiver, or a tool that added padding while rewriting headers.
Either way the file no longer matches what the packager measured, and no amount of re-verification will make the numbers agree.
The fix, and one thing not to do
Re-copy the asset and check again. Use a copy tool that verifies what it wrote.
Do not edit the packing list to match the file you have. It is technically easy and it defeats the entire point of the record, since the declared size exists precisely so that a truncated file cannot pass as complete.