dcpomatic/src, branch playlist DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=playlist 2020-10-18T19:43:03Z macOS build fix. 2020-10-18T19:43:03Z Carl Hetherington cth@carlh.net 2020-10-18T19:43:03Z urn:sha1:6307ce6e9c59aa971413160e88a0f3304879cb95 Tidy up and fix bitmap path finding in the playlist editor. 2020-10-18T18:01:44Z Carl Hetherington cth@carlh.net 2020-10-18T18:01:44Z urn:sha1:ad31022bd9ecabd2c65ee2359f8d859d22fdf84e Fix typo. 2020-10-18T18:00:25Z Carl Hetherington cth@carlh.net 2020-10-18T18:00:25Z urn:sha1:4c0d8ea16deb997ff828767452d3aba560195267 Clarify some error messages on macOS (#1837). 2020-10-17T22:16:25Z Carl Hetherington cth@carlh.net 2020-10-17T22:16:25Z urn:sha1:d0be7e3154fccdf3f2de330d9cf200e01a9f4270 When we say we can't start a particular tool, it may be because it has not even been downloaded/installed. Fix failure to update player information when changing CPLs. 2020-10-17T20:25:40Z Carl Hetherington cth@carlh.net 2020-10-17T20:25:40Z urn:sha1:cddddde3d434656588b37c8b10b366659611f352 Fix deadlock when changing CPL in the player (#1827). 2020-10-17T20:23:12Z Carl Hetherington cth@carlh.net 2020-10-17T20:23:12Z urn:sha1:b33881c9ebe55084434bfea16ba050ad1ba6cb03 TextContent::set_dcp_track can end up requesting a view update, which involves calls to methods in Content which lock the Content::_mutex. Do these calls without a lock on that mutex held. Also, it looks like we would append to texts on every call to examine(). Fix that so that we replace the texts list on each examine() call. Don't crash if the first packet in a stream has AV_NOPTS_VALUE; 2020-10-14T19:24:57Z Carl Hetherington cth@carlh.net 2020-10-14T19:24:57Z urn:sha1:d7a3d94ec307a03ebe3fcf239ba991e9a3c1b8b8 instead, assume it should be at timestamp 0. Clear out _next_time when seeking, so out-of-date values don't 2020-10-14T19:23:36Z Carl Hetherington cth@carlh.net 2020-10-14T19:23:36Z urn:sha1:9a3df0a97b7962c00726447a75599e34c632cb2b hang around. Part of the fix for #1857. Fix errors when over-reading a "large" amount from FileGroups on 2020-10-13T16:51:11Z Carl Hetherington cth@carlh.net 2020-10-06T23:02:47Z urn:sha1:e5277d4042b896c4b50c694fba0f1afb47337f45 Windows. I haven't been able to find any conclusive explanation for why this stuff happens; https://stackoverflow.com/questions/7241168/safe-maximum-number-of-records-read-by-fread is one possible lead. Stop the Windows version of run_ffprobe manipulating the current working directory as tests rely on it. 2020-10-13T16:51:11Z Carl Hetherington cth@carlh.net 2020-10-06T19:37:46Z urn:sha1:a1d3a73736ff2a171ab1160dedf4faea40454bea