Forums » Tutorial and setups »
IPTV - buffering, stalls, general drop outs. Settings that resolved things for me.
Added by J Smith about 7 years ago
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.
When using the pipe:// method with FFMpeg, everything played flawlessly, making me suspect a setting or two somewhere causing problems when using the 'IPTV Automatic' network and importing an M3U with regular HTTP streams - I'd rather not have edited a number of URLs manually to include pipe:// FFmpeg etc! So I started to twiddle some knobs to try and find a solution....
As a few people seemed to also note, when playing the IPtv feeds with VLC directly they would play flawlessly, adding some weight to the IPTV stream not being at fault. Running 2 instances of TVheadend, they would drop out at completely different times, again adding weight to the IPTV stream itself not being at fault.
I'm running the latest 4.3 unstable release at the time of writing, with OSMC frontends running on Raspi3 (with MPEG2 licenses) Key settings for me, are/were as follows, I can't advise the fall-out of changing these settings, but they seem to have more or less completely resolved my issues with IPtv stalling on TVHeadend, whilst I still see some 'service instance is bad, reason: No input detected' in the logs, the feed reconnects and streams without stalling and without skipping back 10 seconds or so and replaying:
- Configuration
- Stream
- Stream Profiles
- Pass
- Timeout 0 (may need to experiment with between 5-10 second)
- Restart on error, Enabled
- Rewrite Service ID, set to 0
- Disable ALL rewrite options (PMT, PAT, SDT, EIT), these settings had the biggest impact for me.
- Save
- Configuration
- Stream
- Stream Profiles
- HTSP
- Timeout 0 (may need to experiment with between 5-10 second)
- Restart on error, Enabled)
- Save
- Configuration
- General
- Base
- Packet Backlog, enabled
- Save
Replies (71)
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by T Pedersen almost 6 years ago
i edited /etc/default/tvheadend file
set TVH debug to 0 and fork logging to with tvhargs < tvheadend.log
- TVH_DEBUG
- if set to 1 will output debug to syslog
TVH_DEBUG=0
- TVH_ARGS
- 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-
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by J Smith almost 6 years ago
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.
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by T Pedersen almost 6 years ago
Ok, good to know. :-)
will not be upgrading to 4.3..
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Jim Grove almost 6 years ago
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:
- Download m3u file
wget "http:/iptv.com/username/xxxxxxxx"
- 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>
- 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!!
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Jim Grove almost 6 years ago
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
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by ian massey almost 6 years ago
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.
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Mario Gidi over 5 years ago
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?
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Rusty Tv over 5 years ago
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]
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Terry Kramer over 5 years ago
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?
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Mario Gidi over 5 years ago
try without the -re
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Terry Kramer over 5 years ago
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.
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Iam Nague about 5 years ago
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 ?
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by J Smith about 5 years ago
I no longer use any IPTV - Pipe was the only thing that worked consistently for me.
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Some Guy almost 5 years ago
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!
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by T Pedersen almost 5 years ago
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
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by M. Bergmann almost 5 years ago
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]]
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by rob p over 4 years ago
T Pedersen,
Would you mind explaining how to use this script or directing me to the right place to find out for myself.
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by T Pedersen over 4 years ago
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.
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Dennis Heim over 4 years ago
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?
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Darek Z. almost 4 years ago
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
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Darek Z. almost 4 years ago
Could anyone help please ?
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Hiro Protagonist almost 4 years ago
You can do this with ffmpeg. Documentation here: https://ffmpeg.org/ffmpeg.html#Stream-selection
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Darek Z. almost 4 years ago
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 :/
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Hiro Protagonist almost 4 years ago
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.
RE: IPTV - buffering, stalls, general drop outs. Settings that resolved things for me. - Added by Troy Boy over 3 years ago
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