DCP-o-matic

Hello All,

Ok so my master file is an Apple ProRes422, and I have had this error twice when running DCP verification in DCP somatic player (even after creating an entirely new master file from scratch).

"The hash of the picture asset j2c_21d0b6dc-4aed-424c-8f44-3c96bb292aed.mxf does not agree with the PKL file. This probably means that the asset file is corrupt."

My previous DCP was made under these circumstances and got kicked back by Simple DCP who did a QC. So, I went ahead and recreated a master file, and just got the same error. The file is on an external drive, I am running Mac OS Sierra 10.12.6

Is this a common error? Any work-arounds or best practices?

Help!!!!

I can only assume that there is a problem with that external drive. Is there enough space on the internal drive to generate that DCP? Can you try a different external drive? What's the format of that external drive?

- Carsten

Carsten, thanks so much for getting back to me.

yes, I was already following this option as a logical next step and it did indeed solve the issue. It is really strange to run into this, as I render to these same external drives for massive after effects projects, as well as use them for avid editing, etc and they never ever have an issue. The drive is formatted Mac OS Extended (Journaled).

Hmm. Occasionally, these USB-SATA Bridges cause trouble during long continuous use. I can only suggest to try a different brand.

- Carsten

That's the thing - I render far longer to single master files using After Effects to the very same drive(s) with zero issues. Renders that go for 9 hours for example, with never a problem.

It's a long shot, but I remember that, when writing to an NTFS partition, a reformat (again to NTFS) solved a similar issue. Now, on a Mac, reformatting an HFS+ drive AGAIN to HFS+ may sound silly...

The strange thing ist, DCP-o-matic creates the hashes for file checks at the end of the DCP creation after it has written these files. This is a read-only process (as far as the actual media files are concerned), but it does not again perform a logical check on these files, it assumes that at the time of hash creation that the media file is 100% intact. So, something must have gone wrong during writing of the file.

It may be that there is something going on that Carl could track down, however, it could be complicated to get a grip on it. I assume that this is a large file, a full length feature?

- Carsten

This all makes sense. I mostly wanted to point out the issue for the development side of the app, as I was able to recreate this issue a few times quite consistently. I am so glad going to the local HD was an easy solution.

I was encoding a 20 minute short.