Tvheadend

i edited /etc/default/tvheadend file

set TVH debug to 0 and fork logging to with tvhargs < tvheadend.log

1. TVH_DEBUG
2. if set to 1 will output debug to syslog
   TVH_DEBUG=0

1. TVH_ARGS
2. add any other arguments
   TVH_ARGS="-l /var/log/tvheadend.log"

and chmod 666 /var/log/tvheadend.log (create it first)
.. and then sudo service tvheadend restart

not sure why this helps, but it does. tried with this and standard syslog back & forward and only this seems to stop the problems with stallings.. couldnt disable it, so this was the alternative. havent tried this with 4.3, but guess it works as same.. did use 4.3 prior with and without ffmpeg fork and the fork worked fine, but 5 sec channel swap was to annoying for me-

Testing with:

4.3-1620~gda5dc10~xenial

Systemd variant of the suggestion above:

OPTIONS="--nosyslog -l /var/log/tvheadend.log -u hts -g video --useragent VLC/2.2.4"

Problem is still apparent, for me at least.. Back to fork, for me.

Ok, good to know. :-)

will not be upgrading to 4.3..

J Smith wrote:

I can't say I've seen that myself, I would have thought thats more the frontend part that makes that decision?

I stumbled across another post that gave me another idea - download the M3U, process it to include the pipe:/// ffmpeg aspects, then import into tvheadend. Something like:

1. Download m3u file
   wget "http:/iptv.com/username/xxxxxxxx"

1. Use perl to process, replace http with the full ffmpeg pipe http
   perl -pi -e 's/^http\:\/\//pipe\:\/\/\/usr\/bin\/ffmpeg\ \-loglevel\ fatal\ \-re\ -\i\ http\:\/\//g' <downloaded m3u file>

1. Find the .ts part of the address, add on tail of ffmpeg command
   perl -pi -e 's/\.ts/\.ts\ \-c\ copy\ \-f\ mpegts\ \-tune\ zerolatency\ pipe\:1/g' <downloaded m3u file>

Then, add a new IPTV Automatic Mux, specify file:///path/to/processed/m3u-file for the URL, disable Use A/V Library if on 4.3, make sure to remember to set a stream limit otherwise you will spawn a shed load of ffmpeg processes!

EDITED: only match http at the beginning of the line, to leave logos alone

I'm having a bit of a problem with the last step here. I think it's because the entries in my playlist file don't contain .ts.

Here's an example of an entry from my playlist file:
pipe:///usr/bin/ffmpeg -loglevel fatal -re -i http://xxxxx.xxxxx:xx/xxxxxx/xxxxxx/xxxx

The first perl bit seems to have worked as it's added the relevant pipe:/// bumf to the beginning of the line.
I think the last perl command needs editing a bit so it works for me, but I don't know how it should look for it to work.

Helllppp!!

Figured it out.

For my scenario I had to use this command as the final step:

sed -i 's/pipe.*/& \-c\ copy\ \-f\ mpegts\ \-tune\ zerolatency\ pipe\:1/g' playlist.m3u

All is working as expected now. Hopefully this will fix the glitchy IPTV and the broken recordings

Does anyone know of any further commands that can be used to restart ffmpeg from pipe when an IPTV stream fails ?

-re -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 300

does not work. I've searched and searched but to no avail. The only solution is to manually switch channels then switch back again to restart the stream. Its doing my head in.

ian massey wrote:

Does anyone know of any further commands that can be used to restart ffmpeg from pipe when an IPTV stream fails ?

-re -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 300

does not work. I've searched and searched but to no avail. The only solution is to manually switch channels then switch back again to restart the stream. Its doing my head in.

Ever found solution to this?

This is what I do. I think it should restart but usually I just restart the channel because I don't want to wait time for it to restart. I suppose you could set the time to be lower for it to restart sooner. Made this using a combination of other things I found online.

ffmpeg-loop.sh

#!/bin/bash

pid=$$
( while [ 1 ]; do bb=$aa; aa=$(stat -L /proc/$pid/fd/1 | grep Modify); if [ "$aa" = "$bb" ]; then pkill -P $pid ffmpeg; echo "kill ffmpeg" >/proc/$pid/fd/2; fi; sleep 10; done )&

while [ 1 ];
do /usr/bin/ffmpeg -loglevel fatal -i "$1" -vcodec copy -acodec copy -f mpegts -tune zerolatency pipe:1
sleep 3
echo "respawn ffmpeg" >&2
done

Then in your m3u you do pipe:///scripts/ffmpeg-loop.sh [source]

I have a IPTV provider that has very dirty transmissions. On all my channels (except one), I experience drops/interruptions, with the typical 3-6 second backup. These dirty patchs occur typically as close as 5 seconds apart, but never more than 120 seconds apart.

Using what I have learned in this conversation, I ended up editing my .m3u file. First I deleted all mux/channels it don't need, which shrunk the .m3u from over 2500 entries to about 60, which is nice for fast mux scanning.

I then edited the http lines to do the ffmpeg piping.

The good part is that TVH recovery time when encountering a interuption is much faster. Does not do any thing for the 3-6 second backups, that is a from the IPTV provider. I also see the same 3-6 second backup with VLC.

The bad is once TVH hits a bad/broken piece, and ffmpeg cleans it up, from that point forward, the audio and video seem to get out of sync. Also the video seems to drop the FPS to a lower rate, and the picture gets very stuttery. If I switch channels and then return, the video returns to the 29-30 fps smooth rate. Until the next dirty stretch is encountered.

The new .m3u entries look like this...
pipe:///usr/bin/ffmpeg -loglevel fatal -re -i http://portal.iptv.com:25461/username/userpassword/131 -c copy -f mpegts -tune zerolatency pipe:1

Does anyone have any suggestions how to further improve my ffmpeg role?

try without the -re

Removed the -re. Things got worse. After encountering the first dirty patch, the audio and vidio would go out of sync by as much as 6-8 seconds.

I read about the -re options. Sounds like it is intended to keep the FPS adjusted correctly.

I encounter same issues with http IPTV streams, especially for streams throughput higher than 5Mbps. I’m not using the pipe workaround but I’ve noticed that streaming the whole “mux” in VLC, everything played flawlessly:
2019-10-15 11:40:48.925 subscription: 0043: "HTTP" subscribing to mux "Test", weight: 10, adapter: "IPTV", network: "IPTV", service: "Raw PID Subscription", hostname="10.8.0.6", client="VLC/3.0.0 LibVLC/3.0.0"

Streaming the mapped “Service” in VLC, with default profile “pass”, gives issues:
2019-10-15 11:55:38.141 subscription: 0044: "HTTP" subscribing to service "Test/Service01", weight: 100, adapter: "IPTV", network: "IPTV", mux: "Test", provider: "FFmpeg", profile="pass", hostname="10.8.0.6", client="VLC/3.0.0 LibVLC/3.0.0"

This makes me crazy, there is definitely something wrong this the “pass” profile and/or Service processing.

Do you have same behavior ?

I no longer use any IPTV - Pipe was the only thing that worked consistently for me.

For anyone using a service without a .ts extension on the http link, the second Perl command for replacement will not work. Revised the regex for a more generic replacement on lines starting with "http://" and combined both prior commands (below). May not work for everyone, but does me and hopefully someone else.

perl -pi -e 's/^(http\:\/\/\S*)/ pipe\:\/\/\/usr\/bin\/ffmpeg\ \-loglevel\ fatal\ \-re\ -\i\ $1 -map\ 0\ -c\ copy\ \-f\ mpegts\ \-tune\ zerolatency\ pipe\:1/g' <downloaded m3u file>

Great thread too, really helped with some problems. Thanks all!

Sharing this script for anyone who want stable iptv with subtitles included into the stream without any buffering issues.

This script uses mplayer for prebuffering and dump it into a file before the continuous ffmpeg pipe stream it out to clients.

#!/bin/bash

trap 'kill -9 $PID && rm -f /home/hts/dump.stream 2>/dev/null' EXIT

rm -f /home/hts/dump.stream

mkfifo /home/hts/dump.stream

mplayer -prefer-ipv4 -cache 8000 -cache-min 80 -really-quiet "$1" -dumpstream -dumpfile /home/hts/dump.stream & PID=$!

pid=$$
( while [ 1 ]; do bb=$aa; aa=$(stat -L /proc/$pid/fd/1 | grep Modify); if [ "$aa" = "$bb" ]; then pkill -P $pid ffmpeg; echo "kill ffmpeg" >/proc/$pid/fd/2; fi; sleep 20; done )&

while [ 1 ]; do
/usr/bin/ffmpeg -loglevel fatal -fflags +igndts -i "/home/hts/dump.stream" -map 0 -c copy -metadata service_provider="Service01" -metadata service_name="FFmpeg" -f mpegts pipe:1
sleep 3
echo "respawn ffmpeg" >&2
done

In case you experience buffer problems, stalls and/or general drop outs, you shouldn't forget your client.
For example using Kodi you should modify/increase the video cache:
[[https://kodi.wiki/Fview/HOW-TO:Modify_the_video_cache]]

T Pedersen,
Would you mind explaining how to use this script or directing me to the right place to find out for myself.

rob p wrote:

T Pedersen,
Would you mind explaining how to use this script or directing me to the right place to find out for myself.

Not sure whats ur hardware, but I`m using a rpi4 w/4gb with rasbian buster, tvh 4.3-1857.

guessing u know the part were u make ffmpeg pipe script and add pipe:///home/hts/script.sh in ur mux.

no guide online for this, but basically its only to install mplayer on ur system and implement it in ur piping script.

With that script, how is the url to access the stream being pushed? I see adding it under the mux as a pipe:///usr/hts/stream.sh, do I just add the url as an argument?

Hi all
After searching internet how to fix freezing channels I found this fix here finally. It works great so far !
I have just a question, which I suppose for right person here, may be very easy to answer.
Is there a way to keep more audio streams, or even all available, when passing the stream to ffmpeg? My iptv provider not always passes my preferred language as the first one. So sometimes the first one is absolutely foreign for me like French or German.
Many thanks
Darek

Could anyone help please ?

You can do this with ffmpeg. Documentation here: https://ffmpeg.org/ffmpeg.html#Stream-selection

Dennis Heim wrote:

With that script, how is the url to access the stream being pushed? I see adding it under the mux as a pipe:///usr/hts/stream.sh, do I just add the url as an argument?

Good point.
Shame it remains not answered :/

Darek Z. wrote:

Dennis Heim wrote:

With that script, how is the url to access the stream being pushed? I see adding it under the mux as a pipe:///usr/hts/stream.sh, do I just add the url as an argument?

Good point.
Shame it remains not answered :/

Disclaimer: I've not used the script nor have I had anything to do with it previously

From reading the script, mplayer is getting its input from "$1", so it looks like the URL should be supplied as the first argument to the script.

Been working with IPTV & TVHeadend for the past 6 months now & this thread helped me lots to improve the process.

Here is the mux pipe that i am using that has greatly improved my experiences

pipe:///usr/bin/ffmpeg -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2000 -probesize 1000k -analyzeduration 0 -fpsprobesize 0 -fflags -nobuffer -err_detect ignore_err -i [urlhere] -codec copy -f mpegts -tune zerolatency pipe:1

The -reconnect arguements have helped greatly as have experieced lots of "end of file" errors where tvheadend would just stall, now ffmpeg reconnects and the stream continues.

The probesize, analyzeduration & fpsprobesize is to speed up the start time of the stream