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
For IPTV, this works out to:
* 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 load
>
> a 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.