Tvheadend

I am also seeing the same issue using both gf59669c (2116) on Fedora 23 X64 and g817f67e (2236) on Fedora 24 ARM 32.

It is definitely a problem on the inbound stream, as it affects watching live streams and recording via DVR. Please note, I am reading MPEGTS via HTTP. It is loaded via a M3U, but this is pure HTTP, not HLS. I have another IPTV network which uses pipe:// streams, which are not affected by this bug, so I think the work around will work. However, this is far from ideal, as I have hundreds of channels on this network, and really don't want to have configure them each individually via pipe streams. Additionally it means I can't take advantage of the regular re-scan of the M3U with automatic IPTV networks to pick up new channels.

Some further notes to help debugging. I can confirm that the stream works well via VLC. I have had both tvheadend and VLC reading the same stream simultaneously, and can confirm that tvheadend stops, and VLC doesn't. Additionally I have had two separate instances of tvheadend playing the same stream and while they both stop occasionally, they don't stop at the same time, so this would seem to be something internal to tvheadend, rather than the stream.

I have performed a packet trace of the stream during failure (see attached file), and can see that during the failure the client (tvheadend) is reporting ZeroWindow, with the host provider sending Keep-Alive's. This indicates that tvheadend has stopped reading packets from the stream, and the OS level receive buffer has filled, and then started reporting back to the host server that it can't receive any more packets. My best guess would be that something in the tvheadend receive thread that is blocking for 30 seconds or more, but my C is not good enough to investigate myself. I can see nothing in the tvheadend logs indicating any other activity is ongoing on other threads when the stream stops, or anything else on the server as well. I haven't tried viewing the tvheadend log with the http client in trace mode, as this spams the logs with every packet received.

I am happy to run additional traces, collected logs, or run any other tests you can suggest.