dcpomatic/src/lib, branch v2.16.98 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.16.98 2024-11-10T01:38:49Z Fix examination logic. 2024-11-10T01:38:49Z Carl Hetherington cth@carlh.net 2024-11-09T11:55:41Z urn:sha1:247191469093427b05229bd0051c25395a30f4b5 Before we would stop if there was one audio stream and the first packet was from that stream; we would not carry on to find the video. I think carry_on_audio should also be set false if audio_packet() returns false. 2024-11-08T18:57:04Z Carl Hetherington cth@carlh.net 2024-11-08T18:57:04Z urn:sha1:111acef9b225731c99274d82cdd374acc04ca252 Remove out-of-date comment. 2024-11-08T18:56:35Z Carl Hetherington cth@carlh.net 2024-11-08T18:56:35Z urn:sha1:153153f2b91297ed463d0a0a85b74bc38f660003 Needing length is the same for audio and video, so merge them. 2024-11-01T00:40:30Z Carl Hetherington cth@carlh.net 2024-10-28T00:36:55Z urn:sha1:8edadeea58faf5c075296df1f605407797e9a25a Obtain audio length by scanning through the file if required (#2880). 2024-11-01T00:40:30Z Carl Hetherington cth@carlh.net 2024-10-19T19:29:54Z urn:sha1:738ced15ead0f029cf2becf9b77d7adf37e733e3 Fix video length when we scan for it. 2024-10-19T19:29:29Z Carl Hetherington cth@carlh.net 2024-10-19T19:29:29Z urn:sha1:24cfca51dffed98f0b115ca36f9a8478753e2432 Length is 1 frame more than the start time of the last frame. Cleanup: initialise a few members in-place. 2024-10-19T18:32:56Z Carl Hetherington cth@carlh.net 2024-10-19T18:32:56Z urn:sha1:027dc03440ff0714b541b810264efa8722c87f39 Tidy up and fix obtaining video length when it's not in the header. 2024-10-19T18:20:00Z Carl Hetherington cth@carlh.net 2024-10-19T18:20:00Z urn:sha1:904538721cf2b69bb8d80059d13ae20e4f256fce I think this has been broken for a while as we would come out of the loop even if we still wanted to find the video length. Give more details when failing to send emails. 2024-10-13T19:15:58Z Carl Hetherington cth@carlh.net 2024-10-13T19:15:58Z urn:sha1:638ce5e0b3bfc690eaf13ecdf82b6cb8817d1585 Fix bug causing signal changes to be lost (#2870). 2024-10-08T17:49:33Z Carl Hetherington cth@carlh.net 2024-10-08T17:49:33Z urn:sha1:3368aefd9782b0e22b95c1bcf988fd9b1c10522e It was possible (and I believe it happend) for new signals to be queued up in _pending while some old ones were being processed. They would then be cleared at the end of resume() without ever being sent.