Thanks, Kino. I agree with you that I think it is a stream quality issue. I suspect some glitch in the signal messes up the process that rejoins all the segments. However, the reality of the situation is that it is almost an impossibility to continuously receive a full hour (or several hour) of wireless signals without some glitch occurring. If such a glitch is going to mess up the entire hour of recording (and even mess up future recordings, as frequently happens), then the DVR is simply not going to be acceptable for antenna usage. I can check the video stream of the TS file recorded with 1.6.1 and see that there are errors in the stream. They are often errors that have no impact on the watching of the file. The errors even ultimately have no impact on other encoding and editing of the TS streams. But, they for some reason cause the whole Plex recording engine to stall. The Plex recording engine should be made to handle these inconsistencies. I can see that it is possible, because 1.6.1 can do it. At least one option is to go back to the 1.6.x manner of recording. Another option is to build in some contingency or error handling. I say this as an engineer/programmer using the product. I obviously don’t know how complicated the coding for this engine is, what the trade-offs between 1.6.1 and 1.9.3 are, and do not mean to sound like I’m complaining. I’m a Plex Pass user, love the software, and am proud to support it. But, a DVR engine that will crash on a minor glitch in a signal is not ready to be labeled for use with antennas, which I suspect the majority of users are doing. Also, a lot of users are probably using those indoor antennas where glitches are common. If the DVR is not made to work with that, there are going to be a lot of complaining users out there.
