Fix the behaviour of FileGroup when seeking too far.

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.

1 files changed, 8 insertions, 2 deletions

diff --git a/src/lib/file_group.cc b/src/lib/file_group.cc
index 9863a21cb..04e23b6b2 100644
--- a/src/lib/file_group.cc
+++ b/src/lib/file_group.cc
@@ -135,12 +135,18 @@ FileGroup::seek (int64_t pos, int whence) const
 		if (sub_pos < int64_t (len)) {
 			break;
 		}
-		sub_pos -= len;
 		++i;
+		if (i < _paths.size()) {
+			/* If we've run out of files we need to seek off the end of the last file */
+			sub_pos -= len;
+		}
 	}
 
 	if (i == _paths.size ()) {
-		return -1;
+		/* Seeking too far isn't an error; we'll seek too far in the last file which
+		 * will "pass on" fseek()'s behaviour to our caller.
+		 */
+		i--;
 	}
 
 	ensure_open_path (i);