Tvheadend

Thank you Robert for that insightful, intelligent, not inflammatory, sensible, adult professional diplomatic response. perfect. you are a credit to the forum.
Having carefully read your explanation I accept the status quo but would cite that tvheaded would benefit from an architecture that more closely resembles IPTV network provision, but as you say it has been created for "conventional" tuning devices ; in this regard I would consider TVH to be probably the class leader certainly on Linux O/Ss. For IPTV users it simply doesnt meet the requirement which is a shame because of all the liveTV servers I have used, TVH is by far the easiest to configure, understand, run and connect to [as client], reliable and with minimal footprint and resource utilisation.

I am a software developer albeit on Windows so MFC/.Net/OLE x86 architecture with the 1000s of WinAPI and classes ; I use c++ mostly but with a sprinkle of Json, Jquery, HTML, VBscript and VB thrown in. It didnt occur to me to simply look at TVH sources but not having ever programmed on Linux it would take me a while to get upto speed on the TVH source and how the general linux OS and app architecture works.

I'm going to have to leave TVH for now, I have installed mythTV and that has correctly read the m3u file, processed it , and correctly generated 755 playable channels Yes the backend took about 15 minutes running on the Pi3 to build the channel list but this isnt much if I run it at 4am every morning, ready for clients to use. BTW, Kodi is only 1 client, I have two linux and one windows clients connecting to this backend. The fact that mysql, mythbackend and mythfrontend run on the Pi as services, with a Total of 10% load (distributed across the 4CPUs (Pi3) ) is a perfect solution. TVheadend seems to serve up data to clients a bit quicker in "user time" but I suspect the addition of mysql might be a consideration.

I look forward to the day that the devs implement some future proofing whereby IPTV is catered for in a more flexible implementation where a simple archtecture where m3u files are processed to create 1 channel per .ts URL. simple, quick, effective, and with all the benefits I describe above. Clearly this wouldnt work where .ts are multiplexed but I dont know any UK IPTV provider - or for that fact any global IPTV provider - that i have come across that multiplexes channels within channel lists , which is what a muxd .ts inside a m3u would be , I mean come on.

So farewell TVH from me, shame.

Daz Egar wrote:

Thank you Robert for that insightful, intelligent, not inflammatory, sensible, adult professional diplomatic response. perfect. you are a credit to the forum.

Sorry my responses were not helpful to you, I did try.

Having carefully read your explanation I accept the status quo but would cite that tvheaded would benefit from an architecture that more closely resembles IPTV network provision, but as you say it has been created for "conventional" tuning devices ; in this regard I would consider TVH to be probably the class leader certainly on Linux O/Ss.* For IPTV users it simply doesnt meet the requirement which is a shame* because of all the liveTV servers I have used, TVH is by far the easiest to configure, understand, run and connect to [as client], reliable and with minimal footprint and resource utilisation.

There are many users that use Tvheadend for IPTV without issue, this is not to say there isn't issues.

I am a software developer albeit on Windows so MFC/.Net/OLE x86 architecture with the 1000s of WinAPI and classes ; I use c++ mostly but with a sprinkle of Json, Jquery, HTML, VBscript and VB thrown in. It didnt occur to me to simply look at TVH sources but not having ever programmed on Linux it would take me a while to get upto speed on the TVH source and how the general linux OS and app architecture works.

I'm going to have to leave TVH for now, I have installed mythTV and that has correctly read the m3u file, processed it , and correctly generated 755 playable channels Yes the backend took about 15 minutes running on the Pi3 to build the channel list but this isnt much if I run it at 4am every morning, ready for clients to use. BTW, Kodi is only 1 client, I have two linux and one windows clients connecting to this backend. The fact that mysql, mythbackend and mythfrontend run on the Pi as services, with a Total of 10% load (distributed across the 4CPUs (Pi3) ) is a perfect solution. TVheadend seems to serve up data to clients a bit quicker in "user time" but I suspect the addition of mysql might be a consideration.

I look forward to the day that the devs implement some future proofing whereby IPTV is catered for in a more flexible implementation where a simple archtecture where m3u files are processed to create 1 channel per .ts URL. simple, quick, effective, and with all the benefits I describe above. Clearly this wouldnt work where .ts are multiplexed but I dont know any UK IPTV provider - or for that fact any global IPTV provider - that i have come across that multiplexes channels within channel lists , which is what a muxd .ts inside a m3u would be , I mean come on.

So farewell TVH from me, shame.

It is indeed a shame :(.

Just out of interest, what service are you using? Don't mention it on here as no doubt it's not going to be legal. send me a mail hello a.t markclarkstone.co.uk.

I do wonder if this whole issue could be avoided if TVHeadend had a setting to reduce the scanning frequency by implementing a fixed delay between requests. From the sound of it, it sounds like the provider only lets users access one channel at a time, and that it is slow to realize when a user is no longer watching a channel. The OP says that MythTV scanned in 755 channels in about 15 minutes so that makes me wonder if they are enforcing a one second delay between scans - that might be just enough time for the IPTV provider to reset its database to show that no channel is currently being watched. Of course it is possible that MythTV doesn't attempt to scan IPTV muxes at all, but in that case why would it take 15 minutes to add 755 channels? So my guess would be that they are scanning, they are just adding a one second sleep between scans.

To be honest TVHeadend's scanning leaves something to be desired even when the source is DVB-S2 satellite, there are conditions where it will fail to scan channels even though they are present and have good signal strength, but that's a whole other issue and I don't want to hijack the thread (only thing I will say is it's probably not waiting long enough before moving on). Just saying, it might be time to consider a rewrite of that part of the code; there's no reason TVHeadend has to try to scan muxes at breakneck speed, and sometimes it misses valid services/channels by moving too fast.

Sean Micklem wrote:

I do wonder if this whole issue could be avoided if TVHeadend had a setting to reduce the scanning frequency by implementing a fixed delay between requests. From the sound of it, it sounds like the provider only lets users access one channel at a time, and that it is slow to realize when a user is no longer watching a channel. The OP says that MythTV scanned in 755 channels in about 15 minutes so that makes me wonder if they are enforcing a one second delay between scans - that might be just enough time for the IPTV provider to reset its database to show that no channel is currently being watched. Of course it is possible that MythTV doesn't attempt to scan IPTV muxes at all, but in that case why would it take 15 minutes to add 755 channels? So my guess would be that they are scanning, they are just adding a one second sleep between scans.

To be honest TVHeadend's scanning leaves something to be desired even when the source is DVB-S2 satellite, there are conditions where it will fail to scan channels even though they are present and have good signal strength, but that's a whole other issue and I don't want to hijack the thread (only thing I will say is it's probably not waiting long enough before moving on). Just saying, it might be time to consider a rewrite of that part of the code; there's no reason TVHeadend has to try to scan muxes at breakneck speed, and sometimes it misses valid services/channels by moving too fast.

No, the scanning of IPTV muxes is different than DVB scanning. As previously stated, the initial scans are needed in order to discover services. The periodic scanning of the M3U playlist for Automatic IPTV networks is different from the "idle scan" that DVB networks have. For IPTV networks, this time period can be set to longer than an hour (I don't recall the max time, though), but you cannot disable it: a value of 0 gives you the default time of an hour.

Also, there is a setting for IPTV networks that will allow you to have multiple simultaneous streams. When creating a network, this value is set to "0" which basically translates to unlimited streams. Most people using IPTV services need to change this to "1", as they are only permitted 1 stream at a time. (Personally I set mine to 3, as my IPTV networks are really HDHR Prime devices that don't work well with Tvheadend's HDHR implementation. Even if your IPTV does not set a limit on the number of streams, you'll probably want to set this to a reasonable number so your initial scan does not try to open 100 streams at once.)

Robert Cameron wrote:

Also, there is a setting for IPTV networks that will allow you to have multiple simultaneous streams. When creating a network, this value is set to "0" which basically translates to unlimited streams. Most people using IPTV services need to change this to "1", as they are only permitted 1 stream at a time. (Personally I set mine to 3, as my IPTV networks are really HDHR Prime devices that don't work well with Tvheadend's HDHR implementation. Even if your IPTV does not set a limit on the number of streams, you'll probably want to set this to a reasonable number so your initial scan does not try to open 100 streams at once.)

Maybe changing that setting would have fixed Daz Egar's problem. I don't know if he realized that needed to be changed.

hi
my simultaneous stream is set to 1
iptv provider only allows 1 connection per client so just 1 channel
look
i keep coming back to the fact that all this about needing to scan muxes to discover services is a bit of a nonsense. I dint know how simple I can say this..
providers, many i have used
our trialled, provide a m3u. in the m3u there is one EXTINF fire Each channel streamed as mpegts . TVH does NOT need to do anything other than create a channel for the stream, I. e, for each ts link. it is so simple. It couldnt be easier but it's being made out to be more complicated than it actuslly is. I totally get the TVH architecture from OTA days but guys this is 2017 and IPTV is here and is the future. yes we can go somewhere else and install another server for our 'requirement' but why not make a great TVH product even greater and provide the killer function. the user wants to provide a play list of ts streams to TVH. may accept the input and create the channels. this obsession about needing to scan is misleading as it is unnecessary. once you get your head round the fact that a ts ONE channel and that the user just wants a list of these as channels to select one for play, irrespective of whether they are on or off, it really is simple

we don't need PMT/PAT verified, provider tags, 'tuning', discovery and all that. TVH is trying to be over complex. just allow the user to define the channels {in m3u}, create the link between channel and URL, and leave it at that.

is so so simple

jeez if I didn't work 8 till 6, six days a week I would change the bloody source myself and offer a pull to git

No one is stopping you from writing a PR against the code. If you feel this really is so simple, then by all means do so. Otherwise, you are just one of the countless people who complain about open source projects, that the free software you have paid nothing to use does not work exactly the way you want it to, and therefore other people who volunteer their time and skills must change the software to work just right for you.

Either learn the software and make it work for you, as many other people seem to have to problem doing, stop complaining about your perceived inconvenience and modify the software to work the way you feel it should, or find another piece of software.

But saying something is easy so other people should do it for you is a crock. Accept it, change it yourself or move on. The code is quite well-written and (mostly) easy to follow, so if you are as skilled a coder as you claim, an afternoon of tweaking C should be no problem.

I will fork it
and take out the shit out

Daz Egar wrote:

I will fork it
and take out the shit out

It's not the feedback, it's the arrogant attitude that accompanied your "feedback". You asked why something could not be done the way you expected it to, and the reason for the current implementation was given. Then you claimed that the way that you expected it to be done would be easy to implement, and in spite of the current architecture and its technical limitations, it should still be done in your manner. At that point was when I said if it was so easy to achieve what you wanted, then you should go ahead and do it.

Once is innocence/ignorance, twice is arrogance.

Robert Cameron wrote:

Daz Egar wrote:

I will fork it
and take out the shit out

It's not the feedback, it's the arrogant attitude that accompanied your "feedback". You asked why something could not be done the way you expected it to, and the reason for the current implementation was given. Then you claimed that the way that you expected it to be done would be easy to implement, and in spite of the current architecture and its technical limitations, it should still be done in your manner. At that point was when I said if it was so easy to achieve what you wanted, then you should go ahead and do it.

Once is innocence/ignorance, twice is arrogance.

I couldn't have said it better myself.

perexg - our only main dev right now, and a few others do their best to try and improve Tvheadend and make it work for everyone. I myself try and help out where I can but due to physical issues I can only do so much.

Pretty much like what Robert has said already, instead of complaining & belittling the project help improve it!

I've broken down your post as it was really hard to read..

Daz Egar wrote:

there, insut exchange over.

No one has once insulted you whatsoever, all that was mentioned was your attitude. An attitude that is clearly shining through in this post.
So far all you've done is complain, you've been given solutions, non of which you even intended to try.

i dint particularly care who does what for who on whatever side, I'm indifferent to that dimension.

I mentioned the people involved because I'd hope you'd understand that there isn't masses of developers working on this project. The way you're coming across is that you expect everything to be halted so that the software is "fixed" just for you.

listen, I come from old school, 68020, z80a, risc assembler , fortran75, cobol, cpm, and days when someone suggested a feature, the excitement and challenge was to implement it within measly resources in 8 bit architecture. coding was an art.

What you're really saying here (again) is that you think the code is "shit" because it doesn't work the way you want. You claim to have the skills to be able to fix it, yet you would rather argue on a forum than help fix it?

I now teach java,. net, jQuery aspx, TV tcpip to students at a large university. what I would say is that these kids who hide behind forums, shout their mouth off, have time on their hands to code ever increasing narcissistic projections of themselves , never quite made it.
no one has recognised them and so they turn to insulting users and 'customers' forgetting the roots of coding, where it all started , and that we do it, to make life easier and more enjoyable to users who are able to exploit technology.
I personally couldn't give a shit what he thinks, I was a 24/7 coder back in my student days, thankfully forums didn't exist then, and we had to go out and meet people, socialise, network, and i have a hunch the angry man here is not someone people find easy to get on with hesitate he is narcissistic, selfish, egotistical, self righteous little boy.

No one here has shouted their mouth off at you. All that's been pointed out was your attitude. So I'm not sure who this is pointed at.

It's a shame really :/

few changes to service.h and service_mapper.c , few more tweaks needed and Im done.
This place is like a schoolground.
good luck ya all

Daz Egar wrote:

few changes to service.h and service_mapper.c , few more tweaks needed and Im done.
This place is like a schoolground.
good luck ya all

If this place is like a schoolyard, you come across like that one awful teacher who thinks they know everything but is often wrong, and even when they are right no one learns anything because they have such a sour attitude.

Ohhhh Shean, that hurt!

Oh well, if we must,

Here is my something , to you , to help you learn...

so, in the codebase there is a file subscriptions.c in which the following <snippet> of code can be seen for a function "subscription_reschedule" ..

/**
/
void
subscription_reschedule(void) {
static int reenter = 0;
th_subscription_t *s;
service_t *t;
service_instance_t *si;
streaming_message_t *sm;
int error, postpone = INT_MAX, postpone2;
assert(reenter == 0);
reenter = 1;

lock_assert(&global_lock);

LIST_FOREACH(s, &subscriptions, ths_global_link) {
if (!s->ths_service && !s->ths_channel) continue;
if (s->ths_flags & SUBSCRIPTION_ONESHOT) continue;

/* Postpone the tuner decision /
/ Leave some time to wakeup tuners through DBus or so */
if (s->ths_postpone_end > mclk()) {
postpone2 = mono2sec(s->ths_postpone_end - mclk());
if (postpone > postpone2)
postpone = postpone2;
sm = streaming_msg_create_code(SMT_GRACE, postpone + 5);
streaming_target_deliver(s->ths_output, sm);
continue;
}

t = s->ths_service;
if(t != NULL && s->ths_current_instance != NULL) {
/* Already got a service */

if(subgetstate(s) != SUBSCRIPTION_BAD_SERVICE)
continue; /* And it not bad, so we're happy */

tvhwarn(LS_SUBSCRIPTION, "%04X: service instance is bad, reason: %s",
shortid(s), streaming_code2txt(s->ths_testing_error));

t->s_streaming_status = 0;
t->s_status = SERVICE_IDLE;

si = s->ths_current_instance;
assert(si != NULL);

subscription_unlink_service0(s, SM_CODE_BAD_SOURCE, 0);

si->si_error = s->ths_testing_error;
time(&si->si_error_time);

if (!s->ths_channel)
s->ths_service = si->si_s;

s->ths_last_error = 0;
}

error = s->ths_testing_error;
si = subscription_start_instance(s, &error);
s->ths_current_instance = si;

if(si == NULL) {
if (s->ths_last_error != error || s->ths_last_find + sec2mono(2) >= mclk()) {
tvhtrace(LS_SUBSCRIPTION, "%04X: instance not available, retrying", shortid(s));
if (s->ths_last_error != error)
s->ths_last_find = mclk();
s->ths_last_error = error;
continue;
}
if (s->ths_flags & SUBSCRIPTION_RESTART) {
if (s->ths_channel)
tvhwarn(LS_SUBSCRIPTION, "%04X: restarting channel %s",
shortid(s), channel_get_name(s->ths_channel));
else
tvhwarn(LS_SUBSCRIPTION, "%04X: restarting service %s",
shortid(s), s->ths_service->s_nicename);
s->ths_testing_error = 0;
s->ths_current_instance = NULL;
service_instance_list_clear(&s->ths_instances);
sm = streaming_msg_create_code(SMT_NOSTART_WARN, error);
streaming_target_deliver(s->ths_output, sm);
continue;
}
/* No service available */
sm = streaming_msg_create_code(SMT_NOSTART, error);
streaming_target_deliver(s->ths_output, sm);
subscription_show_none(s);
continue;
}

subscription_link_service(s, si->si_s);
subscription_show_info(s);
}

while ((s = LIST_FIRST(&subscriptions_remove)))
subscription_unsubscribe(s, 0);

if (postpone <= 0 || postpone == INT_MAX)
postpone = 2;
mtimer_arm_rel(&subscription_reschedule_timer,
subscription_reschedule_cb, NULL, sec2mono(postpone));

reenter = 0;
}

So what this does it basically set a +5 second counter from subscribing to a mux to scan for services. This is the bug-bear for me, because of all the reasons I set out above. What this basically does is lock in a 5 second timeout (in fact it appears to be a 5 second timer not timeout) that must elapse prior to a mux being deemed providing a service (there will only be one per http link in a m3u list of http links, where each link is in fact a channel.

So what?

It appears that some grace time is introduced before the message adding a stream input is created, for every mux scan; TVH creates a mux for every http link (again uncessessary but understandable as the devs had to knife and fork IPTV into existing evolved TVH architecture). TVH passes mutexed messages around to invoke/terminate certain internal functions - quite a good and proven coding methodology.

And i want to make the point here , that some of you lot [well two of you!] keep pushing this nonsense that i am requesting TVH to work the way I want it to, but in fact the reality is that many users will want the same functionality. You can - as I did - even find posts on this VERY forum where members are asking for improved IPTV function surrounding the completely irrelevant use of muxes & sevices - for IPTV. Im sorry to be the bearer of bad news but muxes and services are COMPLETELY irrelevant for IPTV - you do not need to "scan" IPTV as you do for DVB cards across Dbus. It is complete hogwash to suggest that TVH "needs to do this" . Technically, it does not. Period! The reason I suspect the devs "chose" this was infact nothing to do with IPTV per-se but more to do with the architecture of TVH that has evolved over years from DVB card use, where and completely ligitimately, muxers and services are indeed managed through IOCTL across hardware. This is simply NOT the case for (http) IPTV streams where the http layer functionality has everything needed. If one must "scan" a service then all that needs to be done is "tune" to the channel (http link) and decode the PMT/PMA headers to determine a working .ts stream (mpegts). But even then there is an arugment that says "Im not bothered if the channel is online right now, just bloody create the channel so I can watch it later/in future". That is the users perogative if they choose to have this behaviour, i.e. give them everything on offer in the m3u - blindly.

Right, point made, lets get back to that code above. So around 2 seconds (more like upto 5 on my box) per channel to unneccessarily scan for a service. Lets say 3 seconds for each, well at 500 channels (not uncommon if you have UK, USA, Canada, Australia IPTV) well thats around 2,500 seconds to complete the mux scan - FORTY ONE MINUTES ! This is silly for users who want to provide a m3u and just have the channel list "appear" as per DVBLink and MythTV altough mythTV is slow but nowhere near as slow as TVH in creating the channel list.

So what can we do,

well ,

lots of things possible but I would go for just not adding the grace time when dealing with a mpegts mux. This would avoid rewriting much of the code and carry on in the manner the devs have already, to bring IPTV functionality code in. Quite simply then ,to set all timeouts and grace periods for http streams to zero.

Another option is to not create the stream message at all, and just link the mux to a service. This is the code that does this, again from subscriptions.c:-

subscription_link_service(th_subscription_t *s, service_t *t) {
streaming_message_t *sm;
subsetstate(s, SUBSCRIPTION_TESTING_SERVICE);

s->ths_service = t;
  LIST_INSERT_HEAD(&t->s_subscriptions, s, ths_service_link);

tvhtrace(LS_SUBSCRIPTION, "%04X: linking sub %p to svc %p type %i",
           shortid(s), s, t, t->s_type);

pthread_mutex_lock(&t->s_stream_mutex);

if(TAILQ_FIRST(&t->s_filt_components) != NULL ||
     t->s_type != STYPE_STD) {

streaming_msg_free(s->ths_start_message);

s->ths_start_message =
      streaming_msg_create_data(SMT_START, service_build_stream_start(t));
  }

// Link to service output
  streaming_target_connect(&t->s_streaming_pad, &s->ths_input);

streaming_pad_deliver(&t->s_streaming_pad,
                        streaming_msg_create_code(SMT_GRACE,
                                                  s->ths_postpone +
                                                    t->s_grace_delay));

if(s->ths_start_message != NULL && t->s_streaming_status & TSS_PACKETS) {

subsetstate(s, SUBSCRIPTION_GOT_SERVICE);

// Send a START message to the subscription client
    streaming_target_deliver(s->ths_output, s->ths_start_message);
    s->ths_start_message = NULL;
    t->s_running = 1;

// Send status report
    sm = streaming_msg_create_code(SMT_SERVICE_STATUS, 
                   t->s_streaming_status);
    streaming_target_deliver(s->ths_output, sm);
  }

pthread_mutex_unlock(&t->s_stream_mutex);
}

This is more clunky because of this whole interaction between muxes and services, but from what I can see it is simple enough to cut out the stream message request (that checks for valid data from a mux) and just create a service (the http link) to the mux from which the channel is created.

But all this got me thinking,

Why am I spending all this time exploring TVH, just write my own IPTV server that does what I and others want. A simple live TV and record for IPTV only. So I am .....

It's really easy to create the standard IPTV services without any scan - just generate m3u, configure IPTV automatic network and set 'Service ID' (usually 1) and turn off 'Scan after creation'. Dot. TVH also supports direct DVB mux input through the IPTV layer. In this case, the scan is required and one mux (input stream) might have more services. Thus the 'network' - 'mux' - 'service' scheme is VALID and cannot be reduced, if you like to support all MPEG-TS streams.

Jaroslav , you are missing the point , the crux of the issue. Users across the forums want a SIMPLE IPTV setup. This architecture of muxes, services, channel mapping is not necessary and I completely disagree that this scheme is necessary. It simply is not. Look, there are other suites such as DVBLink , DVBViewer, MythTV , VDR and more that do not use this scheme . It is very simple and I fail to see why people are not getting it. A mpegts container contains , for IPTV , a single video stream and a single audio stream. Together this represent one TV channel. Nothing more, nothing, needs to be done other than hold a store of URLs to the .ts source (http) for a given entry in the m3u. Bloody hell, its really straight forward.

Yes there is the possibility that a container can contain more than one channel but here in the UK I have NEVER, never seen this. If there is a provider feeding such streams to the uK and these are being used then pray tell who ??

Look. Im done here, I just dont get why the resistance. I am going to develop my own platform re-using GPL code

WITHOUT muxes and services

oj, and by the way Jaroslav , skipping a scan on muxes fails to create ANY services from which channels can be created

Set the 'Service ID' as I wrote, otherwise TVH does not know which SID is in the stream. The SID is auto-discovered during the scan which you want to avoid. Sorry, but the whole issue seems to me that you do not want to play with a platform which handles many input types. I can argue that if you remove something from the logic, then you'll lose some functionality (like grouping multiple services to a channel to create backups) or so.

I wish you luck with your open software development.

@Daz Egar
With other words
from this

#EXTINF:-1 tvg-id="" tvg-name="UK: FIGHTBOX HD" tvg-logo="http://privider.of.iptv/logos/fightboxhd.png" group-title="Sport",UK: FIGHTBOX HD
http://privider.of.iptv:12345/live/ident/crypt/2679.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: World Fight Channel HD" tvg-logo="" group-title="Sport",UK: World Fight Channel HD
http://privider.of.iptv:12345/live/ident/crypt/3716.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: Fuel HD" tvg-logo="" group-title="Sport",UK: Fuel HD
http://privider.of.iptv:12345/live/ident/crypt/3717.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: Fast&FunBox HD" tvg-logo="" group-title="Sport",UK: Fast&FunBox HD
http://privider.of.iptv:12345/live/ident/crypt/3718.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: EDGE" tvg-logo="http://privider.of.iptv/logos/edgesporthd.png" group-title="Sport",UK: EDGE
http://privider.of.iptv:12345/live/ident/crypt/2765.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: esportsTV HD" tvg-logo="http://privider.of.iptv/logos/esportstv.png" group-title="Sport ONLY",UK: esportsTV HD
http://privider.of.iptv:12345/live/ident/crypt/3878.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: Mio sports 1" tvg-logo="" group-title="Sport",UK: Mio sports 1
http://privider.of.iptv:12345/live/ident/crypt/2609.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: Mio Sports 2" tvg-logo="" group-title="Sport",UK: Mio Sports 2
http://privider.of.iptv:12345/live/ident/crypt/2610.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: Mio Sports 3" tvg-logo="" group-title="Sport",UK: Mio Sports 3
http://privider.of.iptv:12345/live/ident/crypt/2611.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: Mio Sports 4" tvg-logo="" group-title="Sport",UK: Mio Sports 4
http://privider.of.iptv:12345/live/ident/crypt/2612.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: Mio Sports 5" tvg-logo="" group-title="Sport",UK: Mio Sports 5
http://privider.of.iptv:12345/live/ident/crypt/2613.ts
#EXTINF:-1 tvg-id="" tvg-name="UK: Mio Sports 6" tvg-logo="" group-title="Sport",UK: Mio Sports 6

I dont want the "extra functionality" is is not needed. we dont use it. Dont need it. not needed in UK

What do you mean set service ID? where? not in the m3u surely - we dont set that - the provider sets that

'Service ID' is configurable in the TVH's automatic network (expert level). All is in my first comment.

yes, I know how to do it, what I am trying to say is that is wont work 100%

look,

When setting a serviceID on the IPTV Network and unset "Scan after creation", for example, the muxes are created automatically from the M3u file. correct. Then the services are mapped to channels without a scan. correct. HOWEVER, one will find that the channels refer back to the mux UUID for the content stream, where the following holds true:

1. The mux URL points to a locally created file that is fact a simple M3U playlist

2. The locally created file contains:

   #M3U
   #EXTINF <<tags>>
   http://<<ip of localhost>>:9981/stream/.... stream

3. Note:- this translates to a TVH server stream and NOT the remove IPTV stream. The TVH ../stream/.. is thus given to the client , which is fact expecting a mpegts .ts stream. Windows media player is clever enough to work out whats happening, but not TVHclient in Kodi or indeed other native linux clients or android mxPlayer .

4. Now, All this works when using the "Scan after creation" which means the issue is , again , with TVH. If you "Scan after creation" (normal behaviour) then each mux is setup differently where each URL is infact the correct pointer to the .ts content, for example:-

http://some.web.site.com/a-local-url-on-that-server/content.ts

You see, the end result (i.e. able to play a stream) is not the same when using "Scan" and "No Scan" after network creation ! The latter is malformed.

So, it remains to be seen how this "No scan after creation" can actually create a working IPTV setup.

Do you see what I mean? So this brings me back to the OP I raised !

by the way @Jaroslav Kysela , well done for adding this vital info:
Jhttps://tvheadend.org/projects/tvheadend/wiki/Automatic_IPTV_Network/13

excellent tips!