Bug #3843
Tvheadend stop streaming IPTV (synology server)
0%
Description
Tvheadend installed on synology 213J (4.1.2076).
DUring play, after some minutes the image and audio freeze and the bitrate of trasmission goes to zero.
No errors in log, debug and trace. Tvheadend continue working (or recording) without any error but the player does not play anything and the pvr does not record anything.
During play, I have two ways to restart the streaming:
1 - change channel and then go again to the previous channel
2 - go in configuration page in tvheadend, status->connections and click on the red cross to cancel the connection to the client. The stream immediately starts again until the next freeze.
If I am recording, the record finish without any errors but the file only have a few mb recorded (only minutes until the first freeze).
Since there are no errors in logs and in trace, I tried different clients (currently using KODI 16 on raspberry PI3 - OSMC but tried also with VLC from macos) and different IPTV providers but the problem is the same so I am sure that is something within tvheadend.
Same strem with different pvr servers give no problems at all.
Files
Related issues
History
Updated by Jaroslav Kysela over 8 years ago
Updated by What's the type of your IPTV stream? RTP / HTTP / HTTP HLS ?
Updated by Chris Pazz over 8 years ago
Updated by For live TV I am using htsp profile, for recording I am using the pass profile....
Updated by Jaroslav Kysela over 8 years ago
Please, write the type of the IPTV input stream (to TVH)..
Updated by Chris Pazz over 8 years ago
It's HTTP.
The stream is MPEG-TS.
How can I check other info if you need it?
Thank you
Updated by Jaroslav Kysela over 8 years ago
If it's an HLS stream (you get an m3u file when you fetch the URL from command line - wget or curl) then it's probably same as for #3838 .
Updated by Chris Pazz over 8 years ago
Yes, it is a HLS stream then.
I have seen #3838 but I wondering why it is a feature and not a bug....
Anyway, if it is a feature it has to be related to a number of disconnects within a specific time frame and not only a counter (to prevent loops).
Do you have some workaround or know when it is planned? Only for recording that is unattended....
Thank you
Updated by Jaroslav Kysela over 8 years ago
As workaround, you may use ffmpeg as the HTTP client and pipe:// input in TVH.. https://tvheadend.org/projects/tvheadend/wiki/Custom_MPEG-TS_Input
Updated by Chris Pazz over 8 years ago
OK, I am a novice with tvheadend... 
So I will have to change mux settings? I have to put pipe:// in every stream instead of http://?
Sorry for questions but your help is really appreciated....
Updated by 
Updated by
Updated by BoB The Cherub about 8 years ago
Updated by - File record-15-13-31.pcap record-15-13-31.pcap added
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.
Updated by
Updated by BoB The Cherub about 8 years ago
Please note, I don't think #3838 will solve this bug, as the problem is not that the connection is dropping, and needs to be reconnected, but rather TVH is hanging, and no longer reading the connection.
Updated by BoB The Cherub about 8 years ago
I may have found the underlying problem. I think it was a race condition in http_client_unpause. It was being triggered from a timer thread, but it was possible that the httpc thread could reach the pause check in http_client_run0 before hc_pause was reset.
I have created a pull request: https://github.com/tvheadend/tvheadend/pull/909
I've tested on my changes on g817f67e (2236) on Fedora 24 ARM 32, and it seems good. I would welcome anyone else using patches from the above pull request to test on their set-up.
Updated by Philippe Plantegenest over 7 years ago
Updated by - Copied to Bug #4384: Tvheadend stop streaming IPTV added