Fixes a long-standing issue with XML chapter generation for iDevices which I only bothered to really look into recently.
Chapters are basically a hack in mp4, from what I understand, and the way Apple's version of the hack works is as a fake XML subtitle file. Unfortunately, if there isn't a 'blank' chapter after the very last chapter entry, the entire length of the resulting m4v file will be reported as too long. How much longer depends on how much time is left between the last chapter and the end of the video (or audio, whichever is longer). If the last chapter is very, very close to the end of the file (by a second or less) then the added length won't be much - maybe a minute or something. But if it's say, a minute or so before (for example, the start of the end credits on an TV episode) then I've seen this balloon to nearly ten minutes. This messes up the scaling for seekbars and such and in general is just yucky. I've observed this behavior in Kodi (iOS and RPi), MPC-HC, VLC (Windows), and the iOS video player, so it's a widespread issue.
This patch, just a few lines in FileUtil.cs, fixes this behavior across the board by inserting a dummy chapter 500ms after the last one in the input ogm-style chapter file, as calculated using the TimeSpan structure. I've tested it and it works, but feel free to do so yourselves, too. Thanks for all the work on this indispensable tool!
-E
Realized that the previous version of the patch didn't account for an edge-case. The result of the TimeSpan addition operation is now parsed into the proper format to begin with, instead of selecting a substring, which is of a different length when the number of milliseconds is zero - only two digits in that part of string, instead of seven as in every other case, which is then truncated. Less hacky and more importantly, it works - without this change, the entire mux would fail.
Thank you very much. Updated in 2535.
Hurray!