Project

General

Profile

Bug #6036

IPTV Automatic Network streaming freezes after X minutes

Added by Jeremy Williams 5 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
IPTV
Target version:
-
Start date:
2021-04-27
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1952~gb824e237e
Affected Versions:

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

#1

Updated by Jeremy Williams 5 months 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.

#2

Updated by Flole Systems 2 months ago

What's in Tvheadend logs?

#3

Updated by Jeremy Williams 2 months 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.

#4

Updated by Flole Systems 2 months ago

You won't see more error messages, only additional debug output. Probably iptv would be the right subsystem to trace here.

#5

Updated by Jeremy Williams 2 months 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 ?

#6

Updated by Flole Systems 2 months 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.

#7

Updated by Jeremy Williams 2 months ago

Thanks. Will look into it and report back again

#8

Updated by Jeremy Williams about 2 months 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.

#9

Updated by Jeremy Williams about 2 months 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 ?

#10

Updated by Flole Systems about 2 months ago

No, for me it is working even with external IP addresses.

Also available in: Atom PDF