<feed xmlns='http://www.w3.org/2005/Atom'>
<title>dcpomatic/src/lib, branch jenkins</title>
<subtitle>DCP-o-matic DCP tools</subtitle>
<id>https://git.carlh.net/cgit/dcpomatic/atom?h=jenkins</id>
<link rel='self' href='https://git.carlh.net/cgit/dcpomatic/atom?h=jenkins'/>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/'/>
<updated>2020-10-17T20:23:12Z</updated>
<entry>
<title>Fix deadlock when changing CPL in the player (#1827).</title>
<updated>2020-10-17T20:23:12Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-10-17T20:23:12Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=b33881c9ebe55084434bfea16ba050ad1ba6cb03'/>
<id>urn:sha1:b33881c9ebe55084434bfea16ba050ad1ba6cb03</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Don't crash if the first packet in a stream has AV_NOPTS_VALUE;</title>
<updated>2020-10-14T19:24:57Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-10-14T19:24:57Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=d7a3d94ec307a03ebe3fcf239ba991e9a3c1b8b8'/>
<id>urn:sha1:d7a3d94ec307a03ebe3fcf239ba991e9a3c1b8b8</id>
<content type='text'>
instead, assume it should be at timestamp 0.
</content>
</entry>
<entry>
<title>Clear out _next_time when seeking, so out-of-date values don't</title>
<updated>2020-10-14T19:23:36Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-10-14T19:23:36Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=9a3df0a97b7962c00726447a75599e34c632cb2b'/>
<id>urn:sha1:9a3df0a97b7962c00726447a75599e34c632cb2b</id>
<content type='text'>
hang around.  Part of the fix for #1857.
</content>
</entry>
<entry>
<title>Fix errors when over-reading a "large" amount from FileGroups on</title>
<updated>2020-10-13T16:51:11Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-10-06T23:02:47Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=e5277d4042b896c4b50c694fba0f1afb47337f45'/>
<id>urn:sha1:e5277d4042b896c4b50c694fba0f1afb47337f45</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Stop the Windows version of run_ffprobe manipulating the current working directory as tests rely on it.</title>
<updated>2020-10-13T16:51:11Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-10-06T19:37:46Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=a1d3a73736ff2a171ab1160dedf4faea40454bea'/>
<id>urn:sha1:a1d3a73736ff2a171ab1160dedf4faea40454bea</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Stop run_ffprobe from changing the current working directory on Windows.</title>
<updated>2020-10-13T16:51:11Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-10-05T09:15:24Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=1db968e0682b079af2dbaa757015c16433c645e3'/>
<id>urn:sha1:1db968e0682b079af2dbaa757015c16433c645e3</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Make use of default_font_file().</title>
<updated>2020-10-12T15:33:27Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-09-29T20:06:36Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=a839df0d13e463d833f43ed420e8cfd9dda94dff'/>
<id>urn:sha1:a839df0d13e463d833f43ed420e8cfd9dda94dff</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Fix incorrect forward declaration of struct as class.</title>
<updated>2020-10-12T15:33:27Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-09-29T18:51:02Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=b8d0139e5527cff306ffca5ccdc0c1d1df0fb753'/>
<id>urn:sha1:b8d0139e5527cff306ffca5ccdc0c1d1df0fb753</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Remove some Linux hacks that I can't see the point of any more.</title>
<updated>2020-09-29T20:15:56Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-09-29T20:15:56Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=66f66acc99d6de49a038735a2d3236c7a8ceedd3'/>
<id>urn:sha1:66f66acc99d6de49a038735a2d3236c7a8ceedd3</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Go back to add_to_cairo_context rather than show_in_cairo_context.</title>
<updated>2020-09-27T20:50:43Z</updated>
<author>
<name>Carl Hetherington</name>
<email>cth@carlh.net</email>
</author>
<published>2020-09-27T20:50:43Z</published>
<link rel='alternate' type='text/html' href='https://git.carlh.net/cgit/dcpomatic/commit/?id=72c3a5f0f32f553a1f8abee2494f31d29b976383'/>
<id>urn:sha1:72c3a5f0f32f553a1f8abee2494f31d29b976383</id>
<content type='text'>
On Linux, at least, doing

add_to_cairo_context()
fill()
add_to_cairo_context()
stroke()

gives a nicer output than

show_in_cairo_context()

It's not clear exactly what the difference is, but the anti aliasing
looks better and the font outlines basically look smoother.

May help with #1815.
</content>
</entry>
</feed>
