Forums » Tutorial and setups »
.ts incoming stream
Added by Daz Egar over 7 years ago
Hi
Bear with me, I am a new started to TVH
I am using TVH server v3.0.9 on Debian and trying to configure my IPTV.
I have a Source m3u URL remote file at:
http://#url#/get.php#credentials#&type=m3u_plus&ouput=ts
(I have placed # around each parameter part)
which, when downloaded, contains:
- #EXTM3U
#EXTINF:-1 tvg-id="BBC1.uk" tvg-name="BBC One" tvg-logo="" group-title="UK Television",BBC One
http://#ip#:#port#/#url#.ts
...*
and so on
Essentially then, this is a playlist containing MPEG-TS playable streams ?
I have setup a network in TVH and trying to add a URL mux however whatever I seem to put in parameters , achieves nothing. I suspect the URL line in the mux config is wrong ? I can "select channels and play them in VLC by just entering the above Source m3u URL - no probs.
Whatever I do to "scan" doesnt work - something about no data and empty subscription (whatever that is!)
Can anyone propose a suitable setup in the mux config please. Or, do I also have to tweak something somewhere else?
Fantastic bit of software TVH by the way, well done team, just would like to get it working now.
Replies (47)
RE: .ts incoming stream - Added by Robert Cameron over 7 years ago
M3U playlists are supported as inputs for Automatic IPTV networks introduced in 4.1.x. However, they are only used in the same manner as a pre-defined mux list for DVB networks. The URLs for the mux themselves is the same: they must be TS streams.
In your situation, you would need to create a mux that has the http://<ip>:<port>/<path>.ts
portion as its URL, not the URL to the playlist itself.
(Also, Tvheadend 3.x is quite old. You should consider upgrading.)
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
ok. thanks.
but surely, I dontd to create 755 mums? that is how many .ts lines are in the m3u
surely not? if so, then that is not workable
my TVH version is the stock version shipped with my debian install.
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Robert Cameron wrote:
M3U playlists are supported as inputs for Automatic IPTV networks introduced in 4.1.x. However, they are only used in the same manner as a pre-defined mux list for DVB networks. The URLs for the mux themselves is the same: they must be TS streams.
In your situation, you would need to create a mux that has the
http://<ip>:<port>/<path>.ts
portion as its URL, not the URL to the playlist itself.
Yes, this is exactly the issue. It could be easily fixed using a script of some sort. Stupid double playlists!
(Also, Tvheadend 3.x is quite old. You should consider upgrading.)
There was no 3.0.9 release, 2.99, 3.4 and a 3.6 beta though, I think he's using 4.0.9.
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
yes. sorry
4.0.9
im ok with bash so what file or directory is TVH looking in and I will script a conversion and if we're wanting, convert it to a plugin?
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Daz Egar wrote:
yes. sorry
4.0.9im ok with bash so what file or directory is TVH looking in and I will script a conversion and if we're wanting, convert it to a plugin?
I meant you'd have to write a script that changes the urls in your playlist :p
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
eh??
the play list already has .ts URLs in it,
as in my OP
???
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Daz Egar wrote:
eh??
the play list already has .ts URLs in it,
as in my OP???
Yes, but as Robert said above "In your situation, you would need to create a mux that has the http://<ip>:<port>/<path>.ts portion as its URL, not the URL to the playlist itself."
If you were using 4.1, you'd be able to use the Automatic IPTV Network, but you're using 4.0.9 which doesn't have that option.
RE: .ts incoming stream - Added by Sean Micklem over 7 years ago
In 4.0.9 you can try this. First see this article, which talks about adding an audio source:
Basically you will need to do the same thing except that since you are adding video, the URL will be a bit different. It should have this format:
pipe://ffmpeg -loglevel fatal -i http://ADDRESS_OF_STREAM -c copy -flags +global_header -strict -2 -metadata service_provider=PROVIDER_NAME -metadata service_name=PROGRAM_NAME -f mpegts pipe:1
In my experience the ADDRESS_OF_STREAM is usually going to be something with .m3u8 in it somewhere, so your playlist just might work if it's accessible on the web somewhere, but I would not guarantee it. Generally, if you can put the URL into VLC as a Network Source and it will play even a second or two of the video, there's a good chance it will work in TVHeadend. Don't forget that you have to scan the mux just as you would any over the air source, and then add whatever it finds that you want as a channel.
Yes, this is kind of a hack and may require some experimentation to get working, but it does (sometimes) work in 4.0.9.
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
ok - thanks for the links and command spec help
but I keep coming back to the OP, sorry, and the real problem which Im probably not putting across very well.
I totally get URL and pipe and so on, and using ffmpeg to copy the MPEG-TS stream in its raw format with no encoding as .ts files are playable in Kodi. But this is on a PER CHANNEL [stream] basis.
To recap .... I am using a remote m3u8 which contains (now) 755 channels specified correctly as .ts URLs , each one playable in VLC , in fact if I point VLC to the m3u8 file, it correctly lists the individual 755 streams (channels) which I can play. The problem I have is that there seems no way of getting an m3u8 into TVH without mandrolically and rather tediously , adding each stream as a mux. Surely, surely this cannot be the way. It isn't difficult to parse the m3u8 into individual streams and add these as mux's using a script - is this not possible within TVH ? if not , can it not be simply added ? I mean I can write the script but I do not know how to add mux's through - for example - an API ??
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Daz Egar wrote:
ok - thanks for the links and command spec help
but I keep coming back to the OP, sorry, and the real problem which Im probably not putting across very well.
I totally get URL and pipe and so on, and using ffmpeg to copy the MPEG-TS stream in its raw format with no encoding as .ts files are playable in Kodi. But this is on a PER CHANNEL [stream] basis.
To recap .... I am using a remote m3u8 which contains (now) 755 channels specified correctly as .ts URLs , each one playable in VLC , in fact if I point VLC to the m3u8 file, it correctly lists the individual 755 streams (channels) which I can play. The problem I have is that there seems no way of getting an m3u8 into TVH without mandrolically and rather tediously , adding each stream as a mux. Surely, surely this cannot be the way. It isn't difficult to parse the m3u8 into individual streams and add these as mux's using a script - is this not possible within TVH ? if not , can it not be simply added ? I mean I can write the script but I do not know how to add mux's through - for example - an API ??
You're describing "Automatic IPTV Network" in 4.1.
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
ok. I haven't seen it. Its not available in my version of Linux. I will need to do some digging and get hold of a TVH repo. Thanks
EDIT*
Just been here
https://tvheadend.org/projects/tvheadend/roadmap
and Ubuntu packages removed?? So we have to build from source?
EDIT*EDIT*
https://tvheadend.org/projects/tvheadend/wiki/AptRepository
will try that!
well, that didnt work. Im using a Pi3 for the backend, armhf architecture on Jessie debian. No packages and a build from so much source is bound to not work.
Has anyone built armh packages for Jessie?
Could be a mythTV bailout
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Daz Egar wrote:
ok. I haven't seen it. Its not available in my version of Linux. I will need to do some digging and get hold of a TVH repo. Thanks
EDIT*
Just been here
https://tvheadend.org/projects/tvheadend/roadmap
and Ubuntu packages removed?? So we have to build from source?EDIT*EDIT*
https://tvheadend.org/projects/tvheadend/wiki/AptRepositorywill try that!
well, that didnt work. Im using a Pi3 for the backend, armhf architecture on Jessie debian. No packages and a build from so much source is bound to not work.
> Has anyone built armh packages for Jessie?
I'll cook you one.
Could be a mythTV bailout
Here you go:
https://transfer.sh/dMiTj/tvheadend_4.1-2533~g80c52b2_armhf.deb
https://transfer.sh/CzIG6/tvheadend-dbg_4.1-2533~g80c52b2_armhf.deb
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
cheers Mark,
if that's a serious offer?
you would of course be building a package for all armhf{pi} users
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Daz Egar wrote:
cheers Mark,
if that's a serious offer?you would of course be building a package for all armhf{pi} users
I'm going to look into cross compiling on doozer.io for armhf until it's added as an option.
Btw, the links are in the above reply :p
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
hey Mark!
Perfect!
had to install the odd dep , but pretty seamless install - thanks
I did previously attempt a source build from scratch on the Pi, which failed miserably. Too much to post here!
Put your binary deb works a treat
TVH scanning my network now, Ive had to make a few changes such as allowing only 1 input stream and affording 60second timeout on mux scans, it found all muxs though, 755 of them!
Might take a while to scan the muxs - what 60 seconds X 755 !! yikes
Why does it take so long to scan a mux on an IPTV. the channel switch is instant so a stream should be going into TVH pretty instantly. Ive had to allow 60 seconds mux scan otherwise it fails to find the service??
Other than that, seems ok thus far, cant wait till scan is over - next week lol
Cheers Mark
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
Nope, they are failing. IPTV scans on muxes going from PEND, to ACTIVE, to IDLE. The odd one gets the service, but most are FAIL. There is defo a service because I can watch the channels. TVH is allocating 755 mux (correct), 1 service each mux 1 channel each service (correct) but most failing scan. My IPTV provider provides a m3u8 in which the .ts links are inside. When playing a .ts link the source is MPEG-TS with 2 streams, video + audio. My provider only allows one channel to be watched at a time. Could this be where the problem is ?? What do i need to enter into the debug section of the GUI to get a useful log for this?
by the way, if I click play in the mux list for a failed scan, the source downloads as a m3u which j plays fine under Vlc as a channel.
and yes, I'm not watching a channel as I scan, of course.
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Daz Egar wrote:
Nope, they are failing. IPTV scans on muxes going from PEND, to ACTIVE, to IDLE. The odd one gets the service, but most are FAIL. There is defo a service because I can watch the channels. TVH is allocating 755 mux (correct), 1 service each mux 1 channel each service (correct) but most failing scan. My IPTV provider provides a m3u8 in which the .ts links are inside. When playing a .ts link the source is MPEG-TS with 2 streams, video + audio. My provider only allows one channel to be watched at a time. Could this be where the problem is ?? What do i need to enter into the debug section of the GUI to get a useful log for this?
httpc I believe. On the debugging tab, press the Help for options.
by the way, if I click play in the mux list for a failed scan, the source downloads as a m3u which j plays fine under Vlc as a channel.
and yes, I'm not watching a channel as I scan, of course.
Your provider must be rate limiting. Tvheadend generally scans one right after the other, this can sometimes be less than a second.
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
ok Mark, after some debugging, I finally got it all working not, and, with a scan timeout set to 0 so much quick than the 60sec wait before
however,
it is slowly going through all 755 muxs. Is there a way to instruct TVH to forget a subscribing to the mux and just popualate services 1 per mux, given that for IPTV Automatic network using m3u8, there is always only 1 mux and always only 1 service per mux, and I am not bothered about TVH scanning the mux for a valid service - I will just take the hit if anything in the mu38 is wrong to the effect that one of the services doesnt work / no stream/ blank TV screen.
So in other words, assign IPTV Automatic network, no-scan, read list of m3u8 streams and populate a mux and/or channel list from these. Much quicker, much better. At 755 channels on my IPTV, even at what - 4 seconds each that it is taking now to open, subscribe, scan, close each mux - its going to take 50 minutes to scan my IPTV network when all I really want is TVH to just serve up the channel list (working or not) and EPG, to the front end . I mean this has got to be simple to code, just map channels to all muxs - bypass scan (option in menu??)
plz
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Daz Egar wrote:
ok Mark, after some debugging, I finally got it all working not, and, with a scan timeout set to 0 so much quick than the 60sec wait before
however,it is slowly going through all 755 muxs. Is there a way to instruct TVH to forget a subscribing to the mux and just popualate services 1 per mux, given that for IPTV Automatic network using m3u8, there is always only 1 mux and always only 1 service per mux, and I am not bothered about TVH scanning the mux for a valid service - I will just take the hit if anything in the mu38 is wrong to the effect that one of the services doesnt work / no stream/ blank TV screen.
Tvheadend needs to scan each mux to know what services are available, type of streams, etc. It won't just take your word for it. It needs the information for other things, service name, resolution, etc..
So in other words, assign IPTV Automatic network, no-scan, read list of m3u8 streams and populate a mux and/or channel list from these. Much quicker, much better. At 755 channels on my IPTV, even at what - 4 seconds each that it is taking now to open, subscribe, scan, close each mux - its going to take 50 minutes to scan my IPTV network when all I really want is TVH to just serve up the channel list (working or not) and EPG, to the front end . I mean this has got to be simple to code, just map channels to all muxs - bypass scan (option in menu??)
I'm no C dev so I couldn't answer that!
plz
You could always setup a playlist with pipe:// links to a bash script that (on first execute per channel) sends false info to speed it up.
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
I fail to understand, in the context of only IPTV automatic network, why TVH needs to scan. it clearly does not, not to provide the channel certainly. lets look at the facts as the current TVH implementation stands.
1. a playable m3u8 file contain multiple URLs to mpegts format input streams which are, in reality, individually, a channel.
2. TVH 'scans' the input. in reality this is a simple parse of tbe m3u8 to extract streams sources
3. TVH creates ONE mux PER playable stream where each stream is in fact ONE channel
4. TVH then proceeds to 'scan' each mux by 'tuning' to it to extract 'services'. in reality, this is a read of the mpegts stream that we anyway know it's a channel, it may be offline, it may not, but TVH will ONLY create a 'service' if the stream is active with values header info. note: this is undesirable where IPTV providers only allow 1 or maybe 2 connections per client because the provider will drop the connection when it detects multiple clients, as when TVH starts to 'tune' the mux
5. for each 'service', channels can be created and 'played' using ffmpeg pass through, I.e., -vcodec copy -a codec copy -f mpegts. in reality,
6. we anyway already knew the channel list when TVH parsed the m3u. all we cannot say at that time was whether the stream was up and valid, but users may well be providing a valid list anyway and I'd not, may prefer to have the Complete channel list irrespective of whether right now it is offline as this may be quite normal in some situations such as on demand or schedule broadcast.
the point I am making
is that TVH is unnecessarily creating mux's, scanning mux's, creating services. it ONLY needs to in reality create the channel list from the m3u8 EXINF entries and allow users this option. thereby reducing network traffic, allowing users to watch channels whilst a 'scan' is in progress, makes scanning far quicker and reduces system load
a far better experience
TVH sites not need to perform 3,4 or 5. if simply does not.
RE: .ts incoming stream - Added by Daz Egar over 7 years ago
I meant
TVH simply does not need to perform...
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
I'd open a bug/issue on here if it's problematic. I personally don't use IPTV so I can't answer why tvheadend does it this way.
RE: .ts incoming stream - Added by Robert Cameron over 7 years ago
Mark Clarkstone wrote:
… I personally don't use IPTV so I can't answer why tvheadend does it this way.
The reason is inherent to the way Tvheadend is built and its architecture, I believe. From what I can gather by looking at the sources (and when/how different input/network types were added), Tvheadend was originally built for DVB sources. ATSC (and the tuners for this network type) is incredibly similar to DVB, so supporting it was probably not much additional work.
Looking through the input type sources, the hierarchy of things is pretty much this:- Inputs/adapters support network types
- Networks have muxes
- Muxes have services
- Services are mapped to channels
- Input type: Network/internet (as opposed to a particular device/adapter)
- Network: IPTV (a catch-all for all network/internet-based streams
- Mux: URL/URI for a particular resource that points to an MPEG-TS stream (this is important, because all input types in Tvheadend are based around MPEG-TS; if your input stream is a different format such as HLS—think M3U8 playlists—then it cannot parse them, and therefore cannot use them)
- Service: MPEG-TS stream itself (if the URL/URI for an IPTV mux stays the same, but the identifying information about the stream is different such as different Program IDs or something, then Tvheadend treats it as a different service)
So, the difference between the mux and the service is minimal (and nearly non-existent) at first glance, but there really is a difference. It is because of this difference that IPTV muxes still need to be scanned for services. Also, because the MPEG-TS stream that the URL points to can technically still contain multiple programs/services, it is still important that they be scanned for services so Tvheadend can know whether it will need to filter the MPEG-TS stream to only present one program, which cuts down on bandwidth sent to clients.
Tvheadend 4.1.x (which will eventually become 4.2 when its bugs are closed and it is deemed to be feature complete) introduced the Automatic IPTV network type, which is exactly the same as the previous IPTV network, except now it can use M3U playlist files to create muxes automatically without needing to manually enter every URL of every mux. Another advantage to using this network type is that the playlists can use the #EXTINF
attributes to automatically set a few options when the muxes are scanned such as giving them names (which are passed on to the services), as well as which channel names and numbers to assign to the services when they are mapped.
By default, Tvheadend will parse the M3U playlist of Automatic IPTV networks every hour looking for changes. If it finds one, such as a new mux added, it will automatically add that new mux to the network. However, it does not normally scan muxes except upon creation of the network, so you will need to manually scan the new muxes to discover their services. The same thing happens if a URL in the playlist changes: the mux will be considered new/different and it will need to be rescanned in order to discover its services. Similarly, if the Program ID of one of the services that comes from a mux in an IPTV network changes, the old service is no longer considered usable and the channel it pointed to needs to be remapped.
Daz Egar wrote:
I fail to understand, in the context of only IPTV automatic network, why TVH needs to scan. it clearly does not, not to provide the channel certainly. lets look at the facts as the current TVH implementation stands.
1. a playable m3u8 file contain multiple URLs to mpegts format input streams which are, in reality, individually, a channel.
2. TVH 'scans' the input. in reality this is a simple parse of tbe m3u8 to extract streams sources
3. TVH creates ONE mux PER playable stream where each stream is in fact ONE channel
4. TVH then proceeds to 'scan' each mux by 'tuning' to it to extract 'services'. in reality, this is a read of the mpegts stream that we anyway know it's a channel, it may be offline, it may not, but TVH will ONLY create a 'service' if the stream is active with values header info. note: this is undesirable where IPTV providers only allow 1 or maybe 2 connections per client because the provider will drop the connection when it detects multiple clients, as when TVH starts to 'tune' the mux
5. for each 'service', channels can be created and 'played' using ffmpeg pass through, I.e., -vcodec copy -a codec copy -f mpegts. in reality,
6. we anyway already knew the channel list when TVH parsed the m3u. all we cannot say at that time was whether the stream was up and valid, but users may well be providing a valid list anyway and I'd not, may prefer to have the Complete channel list irrespective of whether right now it is offline as this may be quite normal in some situations such as on demand or schedule broadcast.
the point I am making
is that TVH is unnecessarily creating mux's, scanning mux's, creating services. it ONLY needs to in reality create the channel list from the m3u8 EXINF entries and allow users this option. thereby reducing network traffic, allowing users to watch channels whilst a 'scan' is in progress, makes scanning far quicker and reduces system loada far better experience
TVH sites not need to perform 3,4 or 5. if simply does not.
While you may not understand why Tvheadend needs to perform all of these steps, hopefully this will help to clarify a few things as to why these steps all need to happen.
From the content of your previous posts, it sounds as if Tvheadend might not be the solution you are looking for. Since you are using Kodi as your frontend, you may instead wish to use the IPTV Simple PVR client that ships with Kodi, since large lists of internet hosted playlists is not really the use case that Tvheadend was meant to serve. (Of course, with enough patience and creative engineering, you can make Tvheadend do these things … I'm just stating that there are other options which may serve your situation better.)
In any case, I think that most of your questions and concerns have been answered or addressed, albeit perhaps not all with the outcome you were hoping for.
RE: .ts incoming stream - Added by Mark Clarkstone over 7 years ago
Robert Cameron wrote:
.. snip ..
Sorry for hijacking this thread. Robert, have you considered contributing to the Tvheadend 4.1/4.2 docs at all? Judging from your many posts on the forums you'd be great in helping improve the documentation, which is seriously lacking in many areas. I've tried my best but unfortunately personal issues limit the amount of time I can work on them, so any help would be appreciated.