Tvheadend

That should get you started.

Awesome - I will check it out!

But, if using M3U playlists, you should be using the Automatic IPTV network, which is only in 4.1

You know, up until right now I assumed I was on 4.09, but from the about, I think I am running 4.1:

Build: 4.1-2405~geb495a0~xenial

Do you mind pointing me in the direction of where this option is?

EDIT I have found it! I will play around with it and hope to get a better result. Thanks again!

Robert Cameron wrote:

Jean Machine wrote:

Robert Cameron wrote:

Muxes need to be scanned to discover services. And services need to be mapped to channels.

I have gone through this process of mapping services to channels, I believe, but I'm probably doing something wrong. Nothing seems different, and I don't see the correct numbers of channels loaded from the m3u.

I would most definitely appricate a sanity check of my current flow. FYI my m3u file has about 20 channels right now. I've confirmed that it is loading fine when I load it in VLC (VLC playlist will show each item in the liste). After install:
1) configuration tab
2) dvb inputs
3) create one network. added a network name
4) go into muxes and add one, with the url of my m3u file being served over http. added a mux name, added a service name. The scan result is OK/
5) Go into services tab (I believe a service was automatically created for me?)
6) Click ont he one service, click on map selected, click on map selected service
7) Pick the correct service with no other changes
8) Click Map services
9) Service mapper tab opens. Now once I actually saw activity here. Going through the same process again (so i copy my steps specifically) doesn't map anything, it seems.
10) Going back into Muxes, it says 1 channel is loaded. There should be 20 (presumably one channel per entry in the m3u?)

Downloading the m3u playlist from the Mux tab (the play button on the left of the row) will load fine in VLC but it will only show the first video in the m3u list. Ideally this should show everything from my m3u list.

I would most definitely appricate any help here!

If your M3U playlist defines only 1 item, then that might work.

Otherwise, M3U playlists are used with the Automatic IPTV Network type. When you create the network you specify the M3U as part of the creation process. Tvheadend then reads the M3U and creates a mux for each item in the playlist.

Your IPTV muxes should be URLs to a specific stream, not to playlists.

The process should be:

1. Create Automatic IPTV network
2. While creating network, specify URL of M3U (and optionally, max number of streams allowed) This will create a mux in the network for each item in the M3U
3. If you have not selected "Scan upon create", after creating the network, force scan it. This will scan and try to open each mux. For each mux it can successfully open, it will create a service.
4. From the services, map them to channels.

That should get you started. But, if using M3U playlists, you should be using the Automatic IPTV network, which is only in 4.1

AWESOME! Thank you so much for the help! This looks to be exactly what I need to get started. Much appreciated!!

Is there a way to automate this process?
I am refreshing the list every 1 minute, and it seems like, whenever the m3u list gets updated, the only way for any new channels to show up would be for me to go in and create the new channels from the services.

Jean Machine wrote:

Is there a way to automate this process?
I am refreshing the list every 1 minute, and it seems like, whenever the m3u list gets updated, the only way for any new channels to show up would be for me to go in and create the new channels from the services.

No. With an Automatic IPTV network, if the URL in an M3U changes when the Tvheadend scans the M3U, the old mux (and it's services) are removed and the new/updated mux is added as a new mux.

Why are you playlist files constantly changing? That seems a bit odd to me ...

This is because my friends and I like to stream whatever game we're playing, which is done over a pretty extensive vpn I have setup for us (and we prefer to host it ourselves rather than using something public like twitch). We all sign on and off whenever, so I would like it to be up to date for us.

Jean Machine wrote:

This is because my friends and I like to stream whatever game we're playing, which is done over a pretty extensive vpn I have setup for us (and we prefer to host it ourselves rather than using something public like twitch). We all sign on and off whenever, so I would like it to be up to date for us.

For that type of use case, ffserver is probably a better call.

Robert Cameron wrote:

Jean Machine wrote:

This is because my friends and I like to stream whatever game we're playing, which is done over a pretty extensive vpn I have setup for us (and we prefer to host it ourselves rather than using something public like twitch). We all sign on and off whenever, so I would like it to be up to date for us.

For that type of use case, ffserver is probably a better call.

Thank you! I will look into this further, but right away I'm not 100% it will work, as we all end up publishing our own (internal) URLs. Maybe I am overlooking a use case here.

Hi Robert,

Thanks for your 4 step process. It confirms (fortunately:-) that I used the right procedure (tvheadend 4.1-2405~geb495a0~xenial). But I have a problem. My m3u has several hundreds of channels. And scanning them all is taking hours or days. Also the provider allows only one stream, so while scanning, the service is blocked for watching.
Is there a way around the scanning? It shouldn't be needed. I just want tvheadend to assume that all channels are valid and create the muxes and services blindly(without scanning) based on the links in the m3u file.

Regards,

Bert

Scanning a mux is required to generate the service, and the service is what gets linked to the channel. (While the mux and service a basically the same thing with an IPTV stream, it is not always the case.) So, until a mux has a service and is linked to a channel, you can't really tune that mux.

I don't believe that you can create services manually, nor stop Tvheadend from occasionally scanning the m3u for updates to the muxes. This is a problem that is inherent in Tvheadend's design/implementation.

Hi Robert,

That's too bad. Because with a large number of channels and the limitation of a single stream this fails completely.
Just like Raymond mentioned. This is currently not working with tvheadend. And scanning technically is completely unnecessary for IPTV channels. The URL is there and can used for a service.

Is there any work ongoing that you know of to make the IPTV subscriptions work smoother with TVheadend?
I understand it is a underlying design restriction in tvheadend. So it will likely require quite some redesigning.
Does anyone else know about any work in this direction?

Also, you mentioned in an earlier post that IPTV service would only work with an MPEG container format. Luckily, that is the case for me. But it seems to me as an limitation that should be removed somewhere in the future as well. Likely there are other service providers with other stream formats.

Regards,

Bert

If the stream is in a format that ffmpeg recognizes then it should be able to convert it to a format that TVHeadend can use, such as a transport stream (.ts file equivalent). Again I'll mention the thread I posted earlier, which explains how to use ffmpeg in this situation:

https://tvheadend.org/boards/4/topics/23907?r=23925

Still investigating about the error got with "pipe:///usr/bin/ffmpeg -i http://yourstream.mp4/mkv/m3u8 -vcodec copy -acodec copy -f mpegts pipe:1" as mux, going in deep seem that ffmpeg recognize the format correctly but, when analize the stream in the log i see: pipe buffer full

Nannus Coripot wrote:

Still investigating about the error got with "pipe:///usr/bin/ffmpeg -i http://yourstream.mp4/mkv/m3u8 -vcodec copy -acodec copy -f mpegts pipe:1" as mux, going in deep seem that ffmpeg recognize the format correctly but, when analize the stream in the log i see: pipe buffer full

Did you instead try

pipe:///usr/bin/ffmpeg -loglevel fatal -i http://yourstream.mp4/mkv/m3u8 -c copy -flags +global_header -strict -2 -metadata service_provider=Service_Name -metadata service_name=Service_Name_Live_Stream -f mpegts pipe:1

(that's all one line. Replace the two instances of "Service_Name" with the name of the channel or provider)?

EDIT: Or if ffmpeg is in your path then just:

pipe://ffmpeg -loglevel fatal -i http://yourstream.mp4/mkv/m3u8 -c copy -flags +global_header -strict -2 -metadata service_provider=Service_Name -metadata service_name=Service_Name_Live_Stream -f mpegts pipe:1

The above is the only format I have found that works. Some or all of the additional options are necessary.

Thanks for the reply, just tested, mux go ok, but when I try to play mux directly the vlc plugin in firefox show me the pause button (like stream going) but nothing. At the same time tvh log spamming "spawn: Executing "/usr/bin/ffmpeg" " until I close the vlc tab.

(Removed due to incorrect information)

Hi, here again ;P
I'm using RPI3 TVH HTS Tvheadend 4.1-2413

via ssh at prompt find -name ffmpeg:
./usr/bin/ffmpeg
./usr/share/ffmpeg

in tvh mux pipe://usr/bin/ffmpeg -loglevel fatal -i http://xxxxxxxxxxxxxxxxxxxxxxxxxx.mkv -c copy -flags +global_header -strict -2 -metadata service_provider=XXXXXXXXX -metadata service_name=XXXXXXXXX -f mpegts pipe:1
or pipe://usr/share/ffmpeg -loglevel fatal -i http://xxxxxxxxxxxxxxxxxxxxxxxxxx.mkv -c copy -flags +global_header -strict -2 -metadata service_provider=XXXXXXXXX -metadata service_name=XXXXXXXXX -f mpegts pipe:1

iptv: Unable to start pipe 'pipe://usr/share/ffmpeg -loglevel fatal -i http://xxxxxxxxxxxxxxxxxxxxxxxxxx.mkv -c copy -flags +global_header -strict -2 -metadata service_provider=XXXXXXXXX -metadata service_name=XXXXXXXXXX -f mpegts pipe:1' (wrong executable?)

still looking what I'm doing wrong.... ffmpeg different version with different options? I'm thinking about it
(thanks for helping me)

The post about a typo and 3 slashes is incorrect. For using the pipe:// protocol, the command to be executed follows pipe://. If the command is in your $PATH then the initial slash—and therefore, the full path—is not necessary. However, if it is not, or to ensure that a particular binary is used, then you would specify the full path, including the initial "third" slash.

So, you will either have pipe://ffmpeg or pipe:///usr/bin/ffmpeg (assuming your ffmpeg binary is in /usr/bin. pipe://usr/bin/ffmpeg will only work if there is a ffmpeg binary in a usr/bin subdirectory of whatever the current directory of the Tvheadend process is. If for some reason that current directory is /, then the command will work. But most likely it will cause an error.

From the documentation at http://docs.tvheadend.org/webui/config_muxes/ :

pipe://: Read standard output from an external program. If the program name does not have a forward slash (/) as the first character, the PATH environment variable is used to find the program name in all directories specified by PATH. Additional arguments may be separated using spaces.

A note about the -strict option for ffmpeg:

• very (or 2): strictly conform to a older more strict version of the spec or reference software
• strict (or 1): strictly conform to all the things in the spec no matter what consequences
• normal (or 0)
• unofficial (or -1): allow unofficial extensions
• experimental (or -2): allow non standardized experimental things

Hopefully this helps clear a few things up. (I feel it's important to understand what the command you are using actually does, rather than blindly copying someone's howto off the internet, especially because the random howtos are often wrong or filled with incomplete, misleading or out-of-date information.)

Robert Cameron wrote:

The post about a typo and 3 slashes is incorrect. For using the pipe:// protocol, the command to be executed follows pipe://. If the command is in your $PATH then the initial slash—and therefore, the full path—is not necessary. However, if it is not, or to ensure that a particular binary is used, then you would specify the full path, including the initial "third" slash.

So, you will either have pipe://ffmpeg or pipe:///usr/bin/ffmpeg (assuming your ffmpeg binary is in /usr/bin. pipe://usr/bin/ffmpeg will only work if there is a ffmpeg binary in a usr/bin subdirectory of whatever the current directory of the Tvheadend process is. If for some reason that current directory is /, then the command will work. But most likely it will cause an error.

From the documentation at http://docs.tvheadend.org/webui/config_muxes/ :

pipe://: Read standard output from an external program. If the program name does not have a forward slash (/) as the first character, the PATH environment variable is used to find the program name in all directories specified by PATH. Additional arguments may be separated using spaces.

You're right. I'm not a Linux expert, so sometimes I get a little confused. I have removed that incorrect post, and fixed my post above it (again), just in case anyone else discovers this thread. On my system, ffmpeg is in my path, so I just use the pipe://ffmpeg... syntax.

I was just telling you what worked for me, and it was based on something someone else had posted quite some time back, and generally if something works I'm happy and don't go asking too many questions about why. In your case it's obviously not working, and I cannot tell you why. I do recall in the dim recesses of my memory that at one time one of the distributions had started providing avconf (I think it was called, don't quote me on that) rather than ffmpeg, but they either renamed it to ffmpeg or provided some kind of shim program that just passed the call on to avconf. I do recall that you had to make sure that you were using genuine ffmpeg, and that this would not work with the "avconf relabeled as ffmpeg" version. I would be a little surprised if that is your issue, but it's probably worth checking. It's also possible that something about the CPU in the RPi3 is not allowing it to work as shown; I have only ever run TVHeadend on an Intel-based machine.

You can certainly try leaving out the -strict option, or using other values, but I'd be really surprised if that turns out to be the issue.

I wish I could be of more help, but since it works for me I'm kind of out of ideas. Sorry about that. I hope you can get it working.

You misunderstand. I am not having problems with the pipe:// protocol. I have even had a pipe:// working with VA-API hardware encoding via ffmpeg. If anyone is interested, my command lines were:

pipe:///usr/bin/ffmpeg -v error -hide_banner -nostats -i [incoming_stream_url] -c copy -flags +global_header -f mpegts -metadata service_provider=[provider] -metadata service_name=[call_sign] pipe:1

pipe:///usr/bin/ffmpeg -v error -hide_banner -nostats -vaapi_device /dev/dri/renderD128 -i [incoming_stream_url] -vf format=nv12|vaapi,hwupload -c:v h264_vaapi -c:a copy -flags +global_header -f mpegts -metadata service_provider=[provider] -metadata service_name=[call_sign] pipe:1

Robert Cameron wrote:

You misunderstand. I am not having problems with the pipe:// protocol.

Sorry, got you and Nannus Coripot confused. I think I should stop talking now, and just let you guys talk to each other.