dcpomatic/src, branch v2.15.150 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.15.150 2021-05-21T14:24:02Z Fix invalid memory access introduced in 6f832724ef942f133f6f8d0a06d7377beea8f7a6 2021-05-21T14:24:02Z Carl Hetherington cth@carlh.net 2021-05-21T14:24:02Z urn:sha1:0bbcd3880588c5c82f4f19f9465fb2332ea6e0a8 Fix thinko in 4ce4b8d3429a97eb4df63460c7e73863f44a621e 2021-05-21T07:44:51Z Carl Hetherington cth@carlh.net 2021-05-21T07:44:51Z urn:sha1:d652b6dbc655eaa56000620ef55f96badbaa89ff Audio content of course doesn't have a single selected stream, so let's get the channel count from how all the streams are mapped. Tweak crop icon for GTK2 builds (#1997). 2021-05-20T23:25:00Z Carl Hetherington cth@carlh.net 2021-05-20T18:25:48Z urn:sha1:e22855578a329c5cb1b8f431f3f0b73d0d5fa611 Check that wxSystemSettings::GetAppearance() exists. 2021-05-20T21:32:40Z Carl Hetherington cth@carlh.net 2021-05-17T18:35:38Z urn:sha1:9cf9f4c4fbb9de6ae093c348ec798efac200c56d Specify correct number of channels for LEQ(m) analyses of single pieces of content (#1991) 2021-05-20T18:15:14Z Carl Hetherington cth@carlh.net 2021-05-20T18:15:14Z urn:sha1:4ce4b8d3429a97eb4df63460c7e73863f44a621e If we're analysing one piece of content, pass its channel count into the leqm::Calculator rather than just using the film channel count. Don't assert on a non-existant codec (#1999). 2021-05-19T20:54:19Z Carl Hetherington cth@carlh.net 2021-05-19T20:54:19Z urn:sha1:6f832724ef942f133f6f8d0a06d7377beea8f7a6 Don't apply the Windows long path fix twice. 2021-05-11T14:09:20Z Carl Hetherington cth@carlh.net 2021-05-11T14:09:20Z urn:sha1:980336455724bbdb73f3fb3d521e36c71f9345e5 Revert incorrect 'fixing' of path on Windows (#1992). 2021-05-11T12:08:42Z Carl Hetherington cth@carlh.net 2021-05-11T12:08:42Z urn:sha1:60b80e1051c8c20ebce4b757d3fb67491dfdb79d This "to" path is on the ext2 drive so should not have any Windows hacks applied to it. Open a dialogue if pinging the back-end fails on macOS. 2021-05-10T21:35:53Z Carl Hetherington cth@carlh.net 2021-05-10T13:12:23Z urn:sha1:1484f4e3642e3ddcb10515eb0f32b00370968da3 At least this means the user will get another go without losing their setup. My only theory at this point is that sometimes the backend takes a crazy amount of time to start up because of some SIP / gatekeeper type nonsense (#1990). Attempt ping from front- to back-end several times (#1990). 2021-05-09T21:15:05Z Carl Hetherington cth@carlh.net 2021-05-09T14:43:24Z urn:sha1:472959c1357f43e2eb33366c58bed0466474c2b7 On macOS it seems that the backend sometimes is not started very quickly. Adding a long timeout to ping does not work, perhaps because the backend is not listening. Trying a few times seems to fix it. With this fix I saw this log: Sun May 9 23:02:51 2021: dcpomatic_disk_writer e63a485e23 started Sun May 9 23:02:51 2021: Entering main loop Sun May 9 23:02:51 2021: Writer receives command: P from the backend and Sun May 9 23:02:45 2021: Could not send ping to writer (attempt 1) Sun May 9 23:02:47 2021: Could not send ping to writer (attempt 2) Sun May 9 23:02:49 2021: Could not send ping to writer (attempt 3) from the front-end, suggesting that the first 3 pings went to /dev/null and the 4th was heard.