dcpomatic/src/lib/file_group.cc, branch compose DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=compose 2021-07-10T00:02:19Z Use dcp::compose rather than our own. 2021-07-10T00:02:19Z Carl Hetherington cth@carlh.net 2021-07-10T00:02:19Z urn:sha1:5b0e331380c83ec9835e8aa42fd342b2f0ad275d C++11 tidying. 2021-04-30T23:31:35Z Carl Hetherington cth@carlh.net 2021-04-30T23:31:35Z urn:sha1:8963f0007af1a312017b9627c18b82ec2a577591 Fix over-read behaviour of FileGroup to be the same on all platforms. 2020-11-28T19:58:56Z Carl Hetherington cth@carlh.net 2020-11-27T22:30:13Z urn:sha1:cf26869c2789b7ecf91e486fc3c7bf271276a592 Instead of relying on the operating system's behaviour when seeking off the end of a file, keep our own _position. This normalises the behaviour between POSIX and Windows. Fix the behaviour of FileGroup when seeking too far. 2020-11-24T22:01:04Z Carl Hetherington cth@carlh.net 2020-11-24T22:01:04Z urn:sha1:8a1da1da65ba0e6a6fb915c73ff6e6a81da349f2 Previously, if you did a seek off the end of the file group, the seek would return an error. This is not what fseek() does; it returns no error, and preserves the file pointer (returned by ftell()) as if the seek had been successful. fread()s after a too-far seek return no data, of course. Parsing some files (the example used to find the bug was a H264 MP4) involves a seek which is to the byte after the end of the mp4 file. If this fails the whole header parsing fails and DCP-o-matic refuses to use the file. 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. Improve OpenFileError so that it doesn't say "opening for read" 2019-09-29T21:28:57Z Carl Hetherington cth@carlh.net 2019-09-29T21:28:57Z urn:sha1:ab0e8cdcafdcb83096012380f674b8280474e851 in one case where it should say "opening for read/write". Also add some unit tests for ReelWriter. Let's not accept EAGAIN until we're sure it's possible. 2018-12-19T22:24:35Z Carl Hetherington cth@carlh.net 2018-12-19T22:24:35Z urn:sha1:d60fd90a6e13c727a05b629c8c4b93d4bf3b717b Hopefully fix error handling (including EAGAIN) in FileGroup. 2018-12-19T22:16:32Z Carl Hetherington cth@carlh.net 2018-12-19T22:15:34Z urn:sha1:7c3f9fd51051330c8fc58c298b907222d734fa31 Even better open-file error reports. 2016-08-21T21:59:19Z Carl Hetherington cth@carlh.net 2016-08-21T21:59:19Z urn:sha1:92984df6ab50ba4ec90d105e44b58efa863c4b59 Better errors on open fails; remove unused exception. 2016-08-18T16:02:33Z Carl Hetherington cth@carlh.net 2016-08-18T16:02:33Z urn:sha1:513947df0f421c086ac56dff48dfe540b0a380c2