Tvheadend

I have to replace all http links in an m3u too, I do it using pipe & this bash script (modified to give you some ideas).

#!/bin/bash

USER=${1:-username}
PASSWORD=${2:-password}
URL=http://my.playlist.com/playlist
PAT_URL=http://stream.playlist.com
result=$(wget --user ${USER} --password ${PASSWORD} -qO- ${URL})

if [ $? -ne 0 ]; then
    exit 1;
fi

replacement="pipe:///bin/ffmpeg -i" 
echo "${result//$PAT_URL/$replacement \"$PAT_URL\"}" 
exit 0;

All urls should look like..

pipe:///bin/ffmpeg -i http://stream.playlist.com/stream/99999.ts

- Note, I haven't tested this so, it's just an example only..

Thanks. Daft question time... as I'm still baffled:

- Can a network still contain lots of channels, or is it a network per URL?
- Do I replace the URLs in each line of the M3U with the "pipe:" format, and leave the rest of it as is?
- Where do I put the bash script?
- What do I put in the URL, on the Network settings - the bash script or the edited M3U?

...and is there some underlying issue with using ffmpeg on Libreelec, in that it's not actually available...??

What OS are you using?

Dean Steele wrote:

Thanks. Daft question time... as I'm still baffled:

- Can a network still contain lots of channels, or is it a network per URL?

The script will replace all URLs with pipes, so yes it can have lots of channels.

- Do I replace the URLs in each line of the M3U with the "pipe:" format, and leave the rest of it as is?

Pipe just points to an external script/binary, tvh expects mpegts output from it.

- Where do I put the bash script?

Anywhere the hts user can run it, I place mine in /home/hts/

What do I put in the URL, on the Network settings - the bash script or the edited M3U?

Another pipe in the URL field, pipe:///home/hts/iptv.sh.

Dean Steele wrote:

...and is there some underlying issue with using ffmpeg on Libreelec, in that it's not actually available...??

What OS are you using?

Debian.

Thanks!

Reverting to OSMC then - seems to be based on Debian...

I think I'm getting what you're saying, in that I need to amend each line in my iptv.m3u file to list "pipe:" lines instead of the original "http:" entries.

...but I'm confused by that last answer; in the Add IPTV Automatic Network dialog, what do I put against "URL:"?

I'd have usually just put "file:///storage/downloads/iptv.m3u" so I'm unsure what the "iptv.sh" refers to... is that the script mentioned in https://tvheadend.org/issues/3885 or am I missing the point entirely?

Dean Steele wrote:

Thanks!

Reverting to OSMC then - seems to be based on Debian...

I think I'm getting what you're saying, in that I need to amend each line in my iptv.m3u file to list "pipe:" lines instead of the original "http:" entries.

...but I'm confused by that last answer; in the Add IPTV Automatic Network dialog, what do I put against "URL:"?

I'd have usually just put "file:///storage/downloads/iptv.m3u" so I'm unsure what the "iptv.sh" refers to... is that the script mentioned in https://tvheadend.org/issues/3885 or am I missing the point entirely?

So, I rename my amended iptv.m3u to iptv.sh?

Dean Steele wrote:

So, I rename my amended iptv.m3u to iptv.sh?

No, if I'm reading things right, he's given you a script which you can call iptv.sh which he uses to download and modify a .m3u file.

You'll need to modify the script to do what you want [i.e. either download or copy the existing file you have & modify it]. If you then put the path to this script in the URL field as shown, TVH will work with the output of the script.

Obviously you should run the script on the command line & verify it's doing what you want before throwing it at TVH.

Thanks guys - I spent a couple of hours learning about Perl and Bash and such like and worked it out, finally - I've now got three cron jobs converting my m3u links to pipes, and all up and running... but still getting shortened recordings... the hunt continues...

Hiro Protagonist wrote:

.. snip ..

Thanks for stepping in there, I meant to reply sooner but got caught up in other things. Much appreciated!

Dean Steele wrote:

but still getting shortened recordings... the hunt continues...

What streaming profile are you using for recording? I normally use 'matroska' for recording via DVB, but I have created an IPTV recording profile which uses the 'pass' stream profile. This means my IPTV recordings are .ts files, which means skipping forward/back is not as fast as with .mkv, but I find I have fewer dud recordings this way.

However there are some channels that still give problems like you describe, I suspect it's a combination of higher resolution and greater distance to the source, while I do have the bandwidth to stream them, I suspect the higher latency might be causing problems with recording.

Recently I was watching while TVH was recording one of these channels, and the incoming bitrate just dropped to zero after about 15 mins. TVH reported no error. After a few mins of no action I tried streaming from that channel & got nothing, tried a few more & found no IPTV channel worked [I did still have internet connectivity]. At the end of the scheduled time TVH stopped 'recording' & still reported no error. At that point all the IPTV channels started working again.

I was just using "pass" first of all, and then tried "Matroska" but that only recorded Audio, so I went back to "pass" again.

That said, I followed the suggestions in this post; https://tvheadend.org/boards/4/topics/29249; once I'd got my head around Bash and Perl (both the settings and the scripting), and started to see some improvements.

I did work out that most of my "issues" were with the wrong duration being determined by windows/osmc from recorded .TS files though and so found this cunning "fix"; https://tvheadend.org/boards/4/topics/28714; which runs the final file through ffmpeg again, as a post-process, and seems to fix it.

I couldn't get my head around the final step, though; https://tvheadend.org/issues/3885; probably a step too far with my lack of sleep... but I plan to crack it.

I'm sure that solution (a restart of a stream after 20 seconds of 0 bandwidth) will be the cherry on top.

...and it works. I've tested recording several streams over several hours and when the bandwidth drops to zero, the stream is killed and recreated. It's not immediate but it's a radical improvement over a stream of black!

Hiro Protagonist wrote:

However there are some channels that still give problems like you describe, I suspect it's a combination of higher resolution and greater distance to the source, while I do have the bandwidth to stream them, I suspect the higher latency might be causing problems with recording.

Just investigated one of the recordings which failed, it wasn't particularly high resolution - I have higher resolution streams from the same country that don't give me problems.

Trying the respawn script now.