dcpomatic/test, branch v2.17.17DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=v2.17.172024-05-08T06:52:02ZTest build fix.2024-05-08T06:52:02ZCarl Hetheringtoncth@carlh.net2024-05-08T06:52:02Zurn:sha1:b83321a4e3065ca90bed7e329c77ef8f35c3036dFix incorrect file adding during merge.2024-05-08T06:07:24ZCarl Hetheringtoncth@carlh.net2024-05-08T06:07:24Zurn:sha1:ce015c96434474b639fad24a53849fa767a48513Merge remote-tracking branch 'origin/main' into v2.17.x2024-05-07T23:53:50ZCarl Hetheringtoncth@carlh.net2024-05-07T23:53:50Zurn:sha1:6b2119dcd16c43fd681feace00d4e10f464bb9b7Work around deadlock when destroying J2KEncoder with a full writer queue (#2784).2024-05-07T23:33:41ZCarl Hetheringtoncth@carlh.net2024-05-05T19:34:29Zurn:sha1:32d04ddb5c583938f470ed74bda8a50cc2ec9960
This feels like a hack, but I can't think of a nicer way to do it.
The interruption disable makes sense because when we destroy encoder threads
during a DCP encode (because a remote server goes away, for example) we don't
want any frames to be lost due to the encode thread being interrupted between
taking the frame off the queue and sending it to the writer.
When we're destroying the encoder we don't care about this, but I can't see
how you'd differentiate.
Maybe the encoder queue could have two lists: to-do and in-progress;
the encoder thread atomically moves a frame from to-do to in-progress,
but then how do you know when the in-progress ones are orphaned and need
to be re-added to the main queue.
You could make the writer return saying "no" if the queue is full (rather
than blocking and waiting for the queue to empty) but that seems wasteful
as then the frame would be re-encoded.
Use sqlite for cinema and DKDM recipient lists.2024-05-06T18:42:50ZCarl Hetheringtoncth@carlh.net2023-05-20T20:51:49Zurn:sha1:a3fcbb3a76e079a5485a0552ea5d35b8d6739116Cleanup a test and make it a bit more robust.2024-05-06T18:42:18ZCarl Hetheringtoncth@carlh.net2024-05-03T12:37:24Zurn:sha1:330da8967d8ae6366f1992f691e1f472351cfa67Fix failures in real_encode_with_server.2024-04-29T13:48:11ZCarl Hetheringtoncth@carlh.net2024-04-29T08:49:22Zurn:sha1:9d6b7a426b71f1791fc3ad1ac15099892c6709fd
This test suddenly started failing because the server is never found,
so never encodes any frames.
It's a mystery why this started failing, and even more of a mystery
why there seem to be two distinct reasons.
Some failures were apparently due to firewalld blocking UDP broadcast;
disabling the firewall would make the test pass again.
Other failures were apparently caused by an old EncodeServerFinder
hanging around, presumably finding servers before a new one had the
chance.
Apply fixup to test/data submodule and bring it back to the v2.18.x branch.2024-04-24T17:38:24ZCarl Hetheringtoncth@carlh.net2024-04-24T17:38:24Zurn:sha1:17ef19940f152ceeb2e1ad696dd5e7ac5917d8cdRestore time zone to Cinema and improve UI to use it (#2473).2024-04-24T17:12:36ZCarl Hetheringtoncth@carlh.net2024-04-23T23:49:09Zurn:sha1:401da185ca664fc8d819fc842ffc08e14d4f6486Clarify a test result when it fails.2024-04-22T11:03:04ZCarl Hetheringtoncth@carlh.net2024-04-10T08:13:31Zurn:sha1:b74f594ce1dee47fdb5cbeebdc3d6577cdd1cab8