DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.15.153 2021-06-02T08:27:58Z 2021-06-02T08:27:58Z Carl Hetherington cth@carlh.net 2021-05-31T13:45:51Z urn:sha1:d077ad2b75c45b5abea465f5e8bc4a3850a172f3 c432ef98c4cf3b2bda32734983eec3b42b8c3d1e completely broke the relinking of libraries using install_name_tool by only doing it for the x86_64 part of the binaries. This commit fixes that, and also does some tidy up that happened while trying to debug the error. The main cleanup is that --deep is no longer used with codesign, rather we sign all the executables ourselves manually. Various Apple forums suggest that --deep is a Bad Idea for reasons that aren't really clear. For reference, after spending days trying to debug the Gatekeeper refusal to start DoM the way to reveal the problem was: 1. start a clean VM (there are caches everywhere, so once a failure has happened you are even less likely to get any useful logging on the second failure). 2. open "Console" on macOS; logs are written to un-greppable places so you have to use this to see everything. 3. click "start streaming"; I don't know if this step is necessary. 4. put a search term in the search box (e.g. "dcp" for this) 5. start the thing that is not working. And remember that otool without `-arch` on a fat binary will only really operate / look at the first? native? architecture, so if you have an x86_64/arm64 binary and the arm64 parts are wrong you won't see anything about that with `otool -L`, only with `otool -arch arm64 -L` 2021-06-01T23:45:29Z Carl Hetherington cth@carlh.net 2021-06-01T23:45:29Z urn:sha1:fc00f4d30f4b798dd21964d1e9931b94c09f5c06 2021-06-01T15:10:16Z Carl Hetherington cth@carlh.net 2021-06-01T15:10:16Z urn:sha1:4d5d4d96ef3314d3242807c4e610565b769414ee 2021-06-01T15:09:56Z Carl Hetherington cth@carlh.net 2021-06-01T15:09:56Z urn:sha1:1b348977ecc0a8fa31135bf2d554c3d25bafaa2f 2021-06-01T15:09:48Z Carl Hetherington cth@carlh.net 2021-06-01T15:09:48Z urn:sha1:1478a402fbaf1b9d01af70ed81ec5e72d6a9b9a4 2021-06-01T12:25:17Z Carl Hetherington cth@carlh.net 2021-06-01T09:28:48Z urn:sha1:ddd767fd647b2fd585d75ada000d3d01c4c43cb2 It feels neat to have audio language in the audio tab, to match the subtitle language in the subtitle tab. It also avoids the potential confusion of there being an audio language setting in the DCP metadata but no subtitle language setting. However: - I am yet to find a need to describe multiple audio languages in the same DCP (all previous users of Film::audio_languages() were just taking the first language off the list). - As Carsten points out it's fiddly to have to set the audio language for 5 separate-channel WAV files, for example (you wouldn't actually have had to do this, but it would have felt like you did). I think subtitle language remains neater where it is (per-content) as there is this additional subtitle language metadata and it makes much more sense (and is much more likely) that there are multiple subtitle languages in a DCP than it does multiple audio languages. 2021-05-30T22:44:57Z Carl Hetherington cth@carlh.net 2021-05-30T22:44:24Z urn:sha1:8a0ab373363c34daf5d926e951ee79fc422fdb3d Now if you change left and click "link" the right will follow it, and vice versa. 2021-05-30T22:25:25Z Carl Hetherington cth@carlh.net 2021-05-30T22:25:25Z urn:sha1:5b27212aa670a5555b64d2123bb70673987564b4 2021-05-30T22:24:44Z Carl Hetherington cth@carlh.net 2021-05-30T22:24:44Z urn:sha1:7efb39f90c0e70d779fb5f19290851f366f01315 2021-05-30T21:44:23Z Carl Hetherington cth@carlh.net 2021-05-30T21:44:23Z urn:sha1:c982114999f8b9a623ba1c2d8bf45c4466fbd887