DCP Error Reference

More than one asset with the same ID

A UUID is supposed to appear once. Two entries mean two packages have been mixed, or a rewrap reused identifiers it should have regenerated.

The message you saw

The ASSETMAP ... has more than one asset with the same ID.
The PKL ... has more than one asset with the same ID.

These are DUPLICATE_ASSET_ID_IN_ASSETMAP and DUPLICATE_ASSET_ID_IN_PKL in libdcp. The command line and the DCP-o-matic Player word them almost identically, so whichever tool you ran, the text above is what you saw. Our browser check does not detect this condition, which is one reason the local check is a pre-check rather than a substitute for full verification.

Why identifiers have to be unique

Every asset in a DCP is addressed by a UUID rather than by filename, which is what lets a server relocate files and still resolve a composition. Uniqueness is the entire basis of that scheme.

When an identifier appears twice, resolution becomes order-dependent. One server picks the first match, another picks the last, and the same package plays differently in two booths. That is worse than an outright failure, because it passes a spot check and fails at the screening.

How duplicates get created

Copying two DCPs into one folder is the usual route. The packages may share a composition or an audio asset, and the merged folder ends up describing the same UUID from two sources.

Rewrapping tools that reuse identifiers are the other source. A rewrap that changes the essence but keeps the old UUID produces two assets claiming to be the same thing, which is precisely the case the error is designed to catch.

Why we do not suggest editing it

Deleting one of the duplicate entries makes the message go away without establishing which asset the composition intended. If you guess wrong, the package plays the wrong picture and reports clean.

Rebuild instead. Separate the two packages into their own folders and verify each one alone. If the duplicate survives that separation, the package needs re-exporting, because the identifiers themselves are wrong rather than merely colliding.

The free check catches the common failures.

It does not catch this one yet. Run it for structure, references, sizes, and hashes, and treat full verification as a separate step.

Run the free check