@linuxmac, I finally arrived at the same conclusion you did. Turn off the transcoding and the record to .ts worked fine. I updated to 3.0.7300.0 and the issue persists on my Linux box. Looks like I'm going to continue recording to .ts and transcode later.
Digging into this a bit further, I'm right back to my prior thoughts about the problem being corruption of the incoming video stream. In transcoding several of the .ts files with ffmpeg from the CLI I find that the .ts streams have bad data in them. It appears to be dropped frames because In some cases the motion types are bad and in others the ac-text are bad leading to MV errors in P and B frames.
I believe the problem lies in one of two areas: 1.) The computer is having issues recording the .ts file or 2.) The data is being corrupted on the wire. If the former is the issue then Emby _may_ have a play in this. If the latter, then I need to fix my network traffic issues. (This assumes that the HDHomeRun is not the problem.)
So, in either case, the original problem that @linuxmac brought to the table was Emby stopping recording after a period of time. In my case it seems that the recording was stopping short due to corruption of the .ts stream the large number of resulting errors in the transcoding process.
Again, feedback or alternate analysis is appreciated.
Edited by panamajim, 02 October 2016 - 02:51 PM.