dcpomatic/src/lib/j2k_encoder.cc, branch 1575-save-windows DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=1575-save-windows 2025-07-10T18:50:32Z Remove compose.hpp includes. 2025-07-10T18:50:32Z Carl Hetherington cth@carlh.net 2025-07-09T20:58:37Z urn:sha1:bad01065584014aee4024e7cbc4a66acac7617e1 sed -i "/include.*compose.hpp/d;" src/lib/*.cc src/wx/*.cc src/wx/*.h src/tools/*.cc src/lib/*.h test/*.cc Replace String::compose with fmt. 2025-07-10T18:50:32Z Carl Hetherington cth@carlh.net 2025-07-09T20:53:27Z urn:sha1:62c34b28567a097e8f22576e7d7891bd3dbe0ac0 sed -i "/Plural-Forms/n;/%100/n;/scanf/n;s/%[123456789]/{}/g" src/lib/*.cc src/lib/*.h src/wx/*.cc src/tools/*.cc src/lib/po/*.po src/wx/po/*.po src/tools/po/*.po test/*.cc sed -i "s/String::compose */fmt::format/g" src/lib/*.cc src/lib/*.h src/wx/*.cc src/tools/*.cc test/*.cc Don't use an optional for the Grok config object. 2025-03-07T23:12:07Z Carl Hetherington cth@carlh.net 2025-03-03T19:51:48Z urn:sha1:3f2675aab119e55f958563e2fe6949192a2b976d I'm not sure why I did it like this in the first place - perhaps so that if the API endpoint changes there aren't so many old values stuck in config files all over the place? Anyway, it seems cleaner to do it like this, as it's how we handle the other config. Replace assertion with a softer fix. 2024-12-24T22:41:56Z Carl Hetherington cth@carlh.net 2024-12-24T22:28:08Z urn:sha1:ceea64b98c1469b1e34e4897654f9671664203ee Had a report of this assertion tripping with "only servers encode" switched on. The user had encode servers but they were running old software, so wouldn't be enabled for use. Obviously the main DCP-o-matic should not crash in this situation. Log things used to decide on thread counts. 2024-12-24T18:54:56Z Carl Hetherington cth@carlh.net 2024-12-24T18:54:56Z urn:sha1:37b261006bc57df7d1f13f21f46d7fc824ed87ef Fix hang when encoding with GPU enabled but not working. 2024-12-18T09:51:44Z Carl Hetherington cth@carlh.net 2024-12-17T23:17:05Z urn:sha1:f9ab63ab6d2e7eb4b997790e5ca04b38e0ac3f7a Assert if we're about to set up 0 encoding threads. 2024-12-09T00:40:48Z Carl Hetherington cth@carlh.net 2024-12-06T20:28:08Z urn:sha1:22c40636c977fd5b582c242fb918d2aaa498e063 Abort encode if Grok encoder threads are failing (#2899) 2024-11-29T22:31:41Z Carl Hetherington cth@carlh.net 2024-11-28T17:50:21Z urn:sha1:92eab12404eca23db0a96ad7574d8d500f3d0f8a Merge remote-tracking branch 'origin/main' into v2.17.x 2024-05-07T23:53:50Z Carl Hetherington cth@carlh.net 2024-05-07T23:53:50Z urn:sha1:6b2119dcd16c43fd681feace00d4e10f464bb9b7 Work around deadlock when destroying J2KEncoder with a full writer queue (#2784). 2024-05-07T23:33:41Z Carl Hetherington cth@carlh.net 2024-05-05T19:34:29Z urn: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.