Bug #6036
IPTV Automatic Network streaming freezes after X minutes
0%
Description
I have set up an IPTV Automatic Network to stream an h264 live video stream. After X minutes of streaming, video/audio freezes in TVH client. When this happens, client subscription is still alive but bandwidth becomes zero. No errors are shown in TVH logs. Playback does not resume again unless I I stop and re-start the channel manually. This is quite similar to https://tvheadend.org/issues/3843 which already seems to have been fixed.
Some observations:
- If I play the source video stream without TVH (e.g. using ffplay directly), the issue does not happen.
- If I add a ffmpeg pipe in the TVH mux (e.g. pipe:///usr/bin/ffmpeg -i http://url -c copy -f mpegts pipe:1
instead of http://url
) the issue no longer happens.
However this pipe delays stream start by ~2s, which I would like to avoid.
- Streaming profile does not make any difference, happens with both htsp and pass profiles.
- IPTV Client does not make any difference, happens with both Kodi and VLC.
- In the source video stream side, I see the following logs which makes me think TVH stops reading the source stream for some reason:
av_interleaved_write_frame(): Broken pipe
No more output streams to write to, finishing.
Error writing trailer of pipe:1: Broken pipe
Thanks in advance!
History
Updated by Jeremy Williams over 3 years ago
I believe there is some issue regarding IPTV threads.
If I set IPTV threads to 2 -> issue occurs after 10-15 mins of streaming.
If I set IPTV threads to 4 -> this issue occurs after 30-40 mins of streaming.
Updated by Jeremy Williams over 3 years ago
Thanks for the reply. I enabled debug/trace in all subsystems from the UI, but unfortunately could not see any further error-like logs when the issue happens. If there is any other way to debug this, or any patch I could apply to view further debug info please let me now.
Updated by Flole Systems over 3 years ago
You won't see more error messages, only additional debug output. Probably iptv would be the right subsystem to trace here.
Updated by Jeremy Williams over 3 years ago
I checked the logs again with iptv as debug/trace subsystem, but I could not find any errors/warnings the issue occured. The only thing I see is the bandwidth becoming zero in the Status > Subscriptions page when the streaming freezes.
One thing that puzzles me is that the problem goes away if I just add a pipe with ffmpeg in the mux as stated in the description. This is something I would reather avoid due to the delay incurred, but why do you think this is extra pipe is a workaround to the issue ?
Updated by Flole Systems over 3 years ago
Look at the traffic in Wireshark then. Your description sounds like the source is just stopping to send traffic.
No clue why using a pipe works as I don't know why the direct retrieval does not work.
Updated by Jeremy Williams over 3 years ago
Just set up tshark (wireshark cli) to check the traffic between src and dst hosts.
src: streaming server using Jalle19/node-ffmpeg-mpegts-proxy to send the stream using a ffmpeg pipe (wireguard peer)
dst: TVH server connecting to streaming server using IPTV network (wireguard "server")
The streaming froze in the TVH client after 10 minutes of streaming.
At that time, both src and dst wg interfaces still kept sending traffic for like 1 more minute until the ffmpeg pipe closed.
I think that there is no problem with the src, and it is just some issue in the TVH server host causing the ffmpeg pipe to close.
It is unknown why adding an extra ffmpeg pipe at TVH side makes the problem go away (stream can keep going for hours with this extra pipe)
I am using a Raspberry Pi 4 with 2GB RAM as the TVH server, running 32 bit Raspbian.
Will try with a different hardware as the TVH host to check if the problem persists.
Updated by Jeremy Williams over 3 years ago
After further testing, I am experiencing the following:
In TVH, if the URL of the mux is set to:
- the IP of the wireguard (streaming) peer, the freezing issue happens after 10 - 15mins.
- the same IP as the TVH host, but then I redirect with nginx to the wireguard (streaming) peer, the issue no longer happens.
Can there be any issues when using an external IP (different network) in the mux, after streaming for X minutes ?
Updated by Flole Systems over 3 years ago
No, for me it is working even with external IP addresses.