Ahh, possibly this exec - The Go Programming Language
I think the only real way to do it is to use a C app to wrap the modification instead of a shell. Then you'd do your own parsing of argv and modifying the options before passing them along to the real ffmpeg. I just haven't found the motivation yet to experiment more ...
The wrapper script should work, I'm guessing there's a quoting issue breaking when file names have spaces.
Some of the options you listed are required for things to work but you are free to experiment.
Thanks, but was only offering to test DVR beta versions and don't rely on local/remote streaming for web browsers or remote clients (if this code is even used for remote clients).
I'm also not a developer/coder, just a user.
I'll standby and wait for the experts to solve issues as they don't affect me.
I'm no ffmpeg expert, nor do I know your code, but would expect that by removing -hls_flags split_by_time will help with Live TV streaming as you did with streaming recordings to the web browser to ensure each HLS segment is a complete gop for H.264 streams.
discont_start does not meet the RFC8216 specs as used, so thought I would throw that in the mix.
Like I said, I'm just a user and not a coder or expert.
I have spent too much time researching and looking up specs, including RFC8216 and trying different things with ChannelsDVR and am happy to pass the hat to you experts.
I'm uploading a new build without split_by_time which should fix the live tv remux issues.
v2019.04.01.0942 is a winner in my book! 
Removing hls_flags discont_start and split_by_time did the trick.
I tested local streaming to Firefox with Live TV and Recordings, both mpeg2 and h.264 with both hardware and software transcoding.
Will test on iPad Safari next, but it looks great so far.
Does this change affect any Channels clients if they use tuner sharing or force the DVR to transcode?
UPDATE: Tested on iPad using Safari and Channels iOS client with and without both tuner sharing and transcoding. No issues I could find 
1 Like