Thanks. I'll give it a try after my evening recordings finish tonight.
There must be something different about the way the external apps are exec'ed from Go, as wrapping the ffmpeg command seems to fail. (It works in manual testing, but when Channels calls ffmpeg, something else is going on.)
A brief look at the command line options used in the new 2019.03.25.1619 looked like it was using the same options as the previous beta (and therefore still exhibited macroblocking).
For the time being I guess I'll have to plan when I want to watch a program with a bad audio channel and manually switch it over to a beta. Otherwise, the other members from my household won't be happy with the quality loss just to enable me to watch my programs.
I guess you can grab the latest ffmpeg but run it in the last stable release. That will give you the audio fix but keep the old keyframe options.
Unfortunately I'm about to leave on an international trip for a couple weeks so I won't get a chance to investigate this further until I'm back.
I'm not sure I understand. The ffmpeg binary is modified with the audio fix? I thought you were doing something with ffprobe before starting transcoding.
How have you modified the ffmpeg binary?
I could have used ffprobe too, but I opted for a (hacky) ffmpeg patch. Here's a copy: https://gist.github.com/tmm1/b582a40269af75f1f7db61845e29ff58
Ah, that makes sense. I was thinking some detection was happening before the ffmpeg call. However, since ffmpeg is patched and my problem seems to be with the different options it's being called with, putting the newer ffmpeg into an older DVR build makes sense. Thanks for this!
1 Like
If I update to the latest beta and have issues, how do I get back to the latest stable build 2019.03.12.0544?
Long story shortened.
I was spending time testing the beta versions and wanted to try the latest but am about to give up and let others try.
Channels DVR on my Synology NAS appears to only keep the last three versions.
I no longer have the last stable version 2019.03.12.0544.
What I have is;
2019.03.15.1810
2019.03.23.0112
2019.03.24.2249.
You would need to do a reinstall and restore
I'm pushing out a new build which removes -g 0 for now, so things stay stable while I'm away on vacation.
I'm changing this to keep last six as well.
Thanks and enjoy your well deserved vacation.
Don't stream too much from your DVR while in Bali (or wherever vacation is), we want you well rested when you get back 
I would like to replace the following ffmpeg options for live tv streaming to a browser.
Is there any way to test this as racameron stated his wrapper script doesn't work.
replace ( -hls_list_size 3600) with ( -hls_list_size 0)
replace ( -hls_delete_threshold 1) with () , i.e. remove option
replace ( -hls_flags delete_segments+temp_file+discont_start+split_by_time) with ( -hls_flags temp_file)
replace ( -start_number 1) with ( -start_number 0)
I'm running Channels DVR beta v2019.03.26.0218 on a Synology NAS.
I'm not that familiar with Go to really know how options are passed when exec'ing an external system application. I mistakenly thought a simple wrapper script would work, but that's not the case. I'm certain there's a way to achieve, but I'm not certain how to accomplish that.
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