One further thought: I also think it'd be more bulletproof from a content integrity point of view to use existing hashes rather than recalculating them.

For example: Let's say a drive one of the input DCPs is on is faulty and some of the original DCP's data has been corrupted. If the new PKL includes the original hashes from the source PKL, you'll end up with a DCP which has hashes in PKL that don't match the actual content of the files. Which is what you want, because the content has been corrupted, and best outcome is that the server refuses to ingest the DCP, so you're made aware and can get it fixed.

If DOM recalculates the hash from the data on drive, it'll produce a DCP which will pass hash check (because newly calculated hashes match the actual hash of the corrupt data), will happily ingest, but may fail in playback when the server hits the corrupt data.

This scenario isn't entirely academic. We've seen this happen in the wild when someone sought to "fix" a DCP which was failing hash check by just bunging the MXFs into DCP-o-matic and asking it to "rewrap" the content. That produced a new DCP with hashes that matched the content, and so would ingest successfully. But of course this just disguised the corruption, rather than actually fixing it, and the projector conked out halfway through the show.

By the way, sorry for the recent flurry of bug reports. I'm looking to upgrade from 2.14.x to 2.16.x in the next few months, so have been testing things out prior to that.

I agree that dcpomatic2_map should use existing hashes rather then recalculate them.

Also please prioritize using the hashes in the CPL if present (they are optional) as this information are more persistent. ASSETMAP, PKL and VOLINDEX are mainly used for transport and are removed/regenerated on ingest on some servers.

Whereas CPL:s are always kept unchanged, so if hashes are used in the CPL they should have priority.

Please also take a look at the additional suggestions in 0002445

@carl 53b3783a9d493dae07c51d6b99cd238bfcfca5b5

Thanks Carl. Is there a test release I can use to experiment with this change and confirm resolution?

@overlookmotel I can make one - is AppImage best for you?

Thanks Carl. A Mac OS build (10.14) would be preferable if possible.

https://dcpomatic.com/build/main/d21efc8

Let me know if there's any funny business with this build and macOS' "checking" of apps as I had to change how this is done recently and it's hard to know whether it's working or not.

On Mac OS 10.14.6, DOM GUI in the test build opens fine. "Verifying" takes a while (0000001:0000001 min) but that's I don't think unusual vs other DOM versions. I haven't tested any of the other applications - let me know if you'd like me to.

I'll test out dcpomatic2_map later this week.

Mantis! Why you mangle my text? That meant to say verifying takes approx 1 min.

Confirmed fixed in test build d21efc8.

Thanks for checking it out.