IPTV - buffering, stalls, general drop outs. Settings that resolved things for me.

J Smith · 2017-11-01T12:28:29+00:00

Figured I'd share this, as I struggled for a long time with IPTV feeds - they would frequently stall, drop out, replay previous 10 seconds or so, etc. Whe...

Gerrit Gogel

Hey Bob,

Maybe try to open the channel a second time. I think many IPTV providers put channels to "sleep" if they aren't watched. The time to start them up exceeds the maximum timeout in FFmpeg. As you can see in your log the time from starting FFmpeg to closing is almost equal to `-reconnect_delay_max 4294`. Sadly, at the time of writing this parameter cannot be set higher. Also when I stream channels directly with VLC, I experience the same. The first attempt of opening some random channel almost every time fails.

By the way, the value 4294 comes from dividing the maximum value of an unsigned 32bit integer by 1000000. I don't know why FFmpeg devs decided to set this as a max value. Usually, the standard for timeouts is 30 s. 4294 ms just isn't enough.

Gerrit Gogel

I just tested it again and the value is actually seconds, as documented, and not milliseconds. But still for instance in this thread people also report that milliseconds are used instead of seconds: https://superuser.com/questions/1050481/ffmpeg-keep-connection-if-network-source-down

Maybe there is an issue related to specific builds of FFmpeg, where ms are used instead of seconds. No idea.

Gerrit Gogel

Did you maybe set the Data timeout parameter in Stream Profiles to 5s? I wouldn't recommend setting this to a low value. I set mine at 30 s. It means that the stream is closed if the data rate stays at 0 Bytes/s for x seconds. I saw values of 5-10s suggested here, which are too low. I noticed that some streams send data only about every 5-10s, so they would be terminated with this setting.

Bob Birch

I hadn't changed the Data Timeout. It is still at 0. But if I started the strem a second time....it worked!!!

How will that work when TVHeadend goes to record? Is it a VLC issue?

Thanks for the help. I'll see how it goes with doing some recordings.

Bob

Gerrit Gogel

I checked it again and indeed it seems to be a client issue. For instance, I start a channel with VLC, then VLC stops playing the channel if it doesn't receive data for a certain amount of time, which causes tvheadend to close the channel as well. I haven't checked recordings yet.

Greg H

Gerrit Gogel wrote:
> I was fiddling around with my IPTV setup for some days now. I found a lot of helpful information in this thread. Especially the FFmpeg parameters provided by Troy Boy helped a lot.
>
> Here are the full commands I'm using:
>
> Adapt the paths according to your setup.
>
> Download your m3u file:
>
> [...]
>
> If the file has Windows line breaks (CRLF), convert it to Linux line breaks (LF):
> [...]
>
>
>
> Insert the pipe command to every line starting with `http://`: > [...]
>
>
> The FFmpeg command is based on the suggestion made by Troy Boy.
>
> I added `-map 0`, such that every audio and subtitle stream is piped, if multiple are available.
>
> I added `-reconnect_on_network_error 1 -reconnect_on_http_error 1 `, which force FFmpeg to reconnect when a TCP or HTTP error is received. For instance, my provider sometimes gives HTTP 404 errors.
>
> Further, I increased `reconnect_delay_max` to the max value of 4.294 seconds. It determines how long FFmpeg tries to open the stream when an error occurs. Sadly, in some scenarios, even this can be too low. My IPTV provider seems to start streams on demand, meaning if nobody is watching them the stream is "sleeping". This often takes 10-20s. In this case, I have to start the stream a second time. But even with FFmpeg, this problem cannot be solved at the moment, due to the relatively low limit of `reconnect_delay_max`.
>
> In any case, these parameters gave me the best experience. I use Kodi, Emby, and Jellyfin as clients.
>
> EDIT:
> I removed the following parameters because they made the audio become async after a while. I guess because the video FPS isn't determined correctly. I didn't notice any significant change in the stream start-up time.

> `-probesize 1000k -analyzeduration 0 -fpsprobesize 0`

Just tried this with my HDHR and it is working, however the zapping time is really slow. Around 10-15 seconds. Any ideas on the cause?

tvheadend enthusiast

So I limited the output of ffmpeg to loglevel fatal (it was just too much log output as default) but I am also experiencing the slow channel switch time as mentioned above by Greg. Anyone have any ideas on how to fix this? I have .ts piped into the script from m3u4u and then run that through the script.

I want to add that before I piped the stream through ffmpeg I was unable to get recordings to actually keep recording when buffering or drop out occurred during playback. After using the ffmpeg pipe though I now have recordings that actually record correctly. Before using ffmpeg pipe channel switching was pretty quick but after I am experiencing that slow switching time as mentioned by Greg.

For context, my whole setup overall is running on a raspberry pi 4 with 4GB ram, inside a docker container with tvheadend (ran with podman as the other containers are) and then that goes through my vpn container using container network mode for internet access. I then forward the ports for tvheadend through the vpn container (because when using container network mode you can't specify port mappings as well). I am not sure if maybe the pi is just not powerful enough to handle transcoding with ffmpeg quickly or maybe it's the options I have set idk, but would be nice to speed up channel loading/switching times.

Additionally I saw people mentioning something with syslog (I think?) here or so https://tvheadend.org/d/5282-iptv-buffering-stalls-general-drop-outs-settings-that-resolved-things-for-me?r=35521#message-35521 and I am wondering if maybe implementing that would resolve my issues with the slow channel switching?

Sorry for the essay but any feedback is appreciated

Auser Resua

Hi all, this thread has been a great source of things to try and encouragement that possibly I can make IPTV stable enough to use with TVHeadend. The issue I have with many providers is when the stream goes bad, my recordings become unusable. The last few days I have made a bit of a breakthrough and it seems pretty stable. I thought I would share my work with you all to pay it forward and see if it can be improved. One thing I'm not happy with is it doesn't necessarily clean up the processes particularly when a mux scan happens. Anyways here's what I did:

/usr/local/bin/ffmpegin.sh

#!/bin/bash while [ 1 ]; do /opt/ffmpeg-5.1.1-amd64-static/ffmpeg -nostats -reconnect 1 -reconnect_on_network_error 1 -reconnect_on_http_error 1 -reconnect_streamed 1 -reconnect_delay_max 30 -fflags nobuffer -err_detect ignore_err -i $1 -c copy -map 0 -f mpegts pipe:1 1> /home/hts/dump.$2.stream done

/usr/local/bin/ffmpegout.sh

#!/bin/bash /opt/ffmpeg-5.1.1-amd64-static/ffmpeg -nostats -follow 1 -err_detect ignore_err -i /home/hts/dump.$1.stream -c:a aac -c:v mpeg2video -b:v 12M -map 0 -f mpegts pipe:1

/usr/local/bin/linker.sh

#!/bin/bash pid=$$ echo "main pid is $pid" | logger -t ffmpeg-linker trap 'echo "Caught trap, ffmpegin.sh pid is $PID" | logger -t ffmpeg-linker && rm -f /home/hts/dump.$pid.stream && trap - SIGTERM && kill -- -$$ | logger -t ffmpeg-linker' EXIT SIGINT SIGTERM rm -f /home/hts/dump.$pid.stream mkfifo /home/hts/dump.$pid.stream /usr/local/bin/ffmpegin.sh $1 $pid & PID=$! echo "ffmpegin.sh pid is $PID" | logger -t ffmpeg-linker /usr/local/bin/ffmpegout.sh $pid rm -f /home/hts/dump.$pid.stream

And of course, you need some kind of filter for your m3u file to add the pipe command to the front of each line: pipe:///usr/local/bin/linker.sh

This approach needs a bit of grunt in your machine too, I've got an old 2.5Ghz Xeon and each recording uses about 2 cores.

jon will

Auser Resua wrote:
> Hi all, this thread has been a great source of things to try and encouragement that possibly I can make IPTV stable enough to use with TVHeadend. The issue I have with many providers is when the stream goes bad, my recordings become unusable. The last few days I have made a bit of a breakthrough and it seems pretty stable. I thought I would share my work with you all to pay it forward and see if it can be improved. One thing I'm not happy with is it doesn't necessarily clean up the processes particularly when a mux scan happens. Anyways here's what I did:
>
> /usr/local/bin/ffmpegin.sh
> [...]
>
> /usr/local/bin/ffmpegout.sh
> [...]
>
> /usr/local/bin/linker.sh
> [...]
>
>
> And of course, you need some kind of filter for your m3u file to add the pipe command to the front of each line: pipe:///usr/local/bin/linker.sh
>

> This approach needs a bit of grunt in your machine too, I've got an old 2.5Ghz Xeon and each recording uses about 2 cores.

Can someone give me a step by step guide on how to implement this? I'm OK with linux but new to TVheadend.

julien julien

> This approach needs a bit of grunt in your machine too, I've got an old 2.5Ghz Xeon and each recording uses about 2 cores.

Thanks a lot i try for the moment all is ok

Nothing to do just create file in good folder and add

pipe:///usr/local/bin/linker.sh http://linkofvideo in your m3u

for me just change
/opt/ffmpeg-5.1.1-amd64-static/ffmpeg
to

ffmpeg

and I add
-user_agent Kodi/18

in /usr/local/bin/ffmpegin.sh after ffmpeg because my iptv provider block ffmpeg user agent

and change /usr/local/bin/ffmpegout.sh for have good quality

ffmpeg -nostats -follow 1 -err_detect ignore_err -i /home/hts/dump.$1.stream -c copy -map 0 -f mpegts pipe:1

thanks

Tachioma

In case this helps anyone coming across this : https://tvheadend.org/d/9048-script-to-update-iptv-muxes

« Previous Page