Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] Ticket #2415: wrong select for active eitscanning

Index | Next | Previous | View Threaded

janne-mythtv at grunau

Sep 24, 2006, 9:06 AM

Post #1 of 4 (805 views)
Permalink

Re: [mythtv-commits] Ticket #2415: wrong select for active eitscanning

On Sunday 24 September 2006 11:06, MythTV wrote:
> #2415: wrong select for active eitscanning
>
> Janne, with your patch the select returns only one channum and not
> one channum per transponder.

Yeah, I saw just after I attached the patch. Since trac doesn't sent
mails for new attachments I thought nobody would notice the patch until
I commit a working one, sorry.
But munging the channum in the original patch is wrong since we need it
later for tuning.

> But I think a better way for getting the channels for active
> eitscanning is to use the one with the lowest service id per
> transponder.

I select now "channum, MIN(chanid)". Later we will use only the
multiplex.

> I don't know how other providers act, but the German
> Provider Premiere use two channels for special eit for the sport and
> ppv channels. Both channels are on different transponders and have
> the lowest service id. It might be coincidence, but I think it is
> intention.

I had only a brief look on the patch for EIT on the special channels.
But I don't see, why you need to use the portal channings as tuning
channels. You might activate additional PIDs based on the portal
channels but that isn't a good solution.
I also dislike the huge code duplication in eithelper.cpp.

Janne
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mythtv at linux-dude

Sep 24, 2006, 9:47 AM

Post #2 of 4 (743 views)
Permalink

Re: [mythtv-commits] Ticket #2415: wrong select for active eitscanning [In reply to]

Janne Grunau schrieb:
> On Sunday 24 September 2006 11:06, MythTV wrote:
>> #2415: wrong select for active eitscanning
>>
>> Janne, with your patch the select returns only one channum and not
>> one channum per transponder.
>
> Yeah, I saw just after I attached the patch. Since trac doesn't sent
> mails for new attachments I thought nobody would notice the patch until
> I commit a working one, sorry.
> But munging the channum in the original patch is wrong since we need it
> later for tuning.
>

OK, I see this point.

>> But I think a better way for getting the channels for active
>> eitscanning is to use the one with the lowest service id per
>> transponder.
>
> I select now "channum, MIN(chanid)". Later we will use only the
> multiplex.
>
>> I don't know how other providers act, but the German
>> Provider Premiere use two channels for special eit for the sport and
>> ppv channels. Both channels are on different transponders and have
>> the lowest service id. It might be coincidence, but I think it is
>> intention.
>
> I had only a brief look on the patch for EIT on the special channels.
> But I don't see, why you need to use the portal channings as tuning
> channels. You might activate additional PIDs based on the portal
> channels but that isn't a good solution.

The eit data is only provided on special pids (0xb11 and 0xb12) on the
two portal channels. Therefore it is necessary at the moment, that the
active eitscanner gets the channums for this channels.
How will the eitscanner work in future when you only use the multiplex?

> I also dislike the huge code duplication in eithelper.cpp.
>

This is caused by the different structure of the event tables and at the
moment I don't know if there is a better way for the integration, but I
will have a look at it.

Wolfgang

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

janne-mythtv at grunau

Sep 24, 2006, 11:01 AM

Post #3 of 4 (736 views)
Permalink

Re: [mythtv-commits] Ticket #2415: wrong select for active eitscanning [In reply to]

On Sunday 24 September 2006 18:47, Wolfgang Nothdurft wrote:
> > I had only a brief look on the patch for EIT on the special
> > channels. But I don't see, why you need to use the portal channings
> > as tuning channels. You might activate additional PIDs based on the
> > portal channels but that isn't a good solution.
>
> The eit data is only provided on special pids (0xb11 and 0xb12) on
> the two portal channels. Therefore it is necessary at the moment,
> that the active eitscanner gets the channums for this channels.

I can't find anything in the patch attached to #2418 that makes it
important to which channel the eitscanner tunes. You enable listening
on the special EIT PIDs unconditional.
We might find in the Premiere service information something that
indicates if we should listen on these PIDs.
Otherwise a simple solution is to activate it based on the original
network id (and transport id).

> How will the eitscanner work in future when you only use the
> multiplex?

Not much different than now. EIT is independent of the channels.

> > I also dislike the huge code duplication in eithelper.cpp.
>
> This is caused by the different structure of the event tables and at
> the moment I don't know if there is a better way for the integration,
> but I will have a look at it.

I had first the impression that the PremiereEventInformationTable is
basicly an EIT but it can hold additional descriptors. Do you have docs
for the premiere private sections and descriptors?

Janne
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mythtv at linux-dude

Sep 24, 2006, 1:45 PM

Post #4 of 4 (743 views)
Permalink

Re: [mythtv-commits] Ticket #2415: wrong select for active eitscanning [In reply to]

Janne Grunau schrieb:
> On Sunday 24 September 2006 18:47, Wolfgang Nothdurft wrote:
>>> I had only a brief look on the patch for EIT on the special
>>> channels. But I don't see, why you need to use the portal channings
>>> as tuning channels. You might activate additional PIDs based on the
>>> portal channels but that isn't a good solution.
>> The eit data is only provided on special pids (0xb11 and 0xb12) on
>> the two portal channels. Therefore it is necessary at the moment,
>> that the active eitscanner gets the channums for this channels.
>
> I can't find anything in the patch attached to #2418 that makes it
> important to which channel the eitscanner tunes. You enable listening
> on the special EIT PIDs unconditional.

That's right, but it's not like the standard EIT PID 0x12 which is sent
on all channels. It is really only available on these two channels. PID
0xb11 on service id 18 and PID 0xb12 on service id 17.
I think it is conditional cause the listener only would be added if the
pid is in the cur_pid list.

> We might find in the Premiere service information something that
> indicates if we should listen on these PIDs.
> Otherwise a simple solution is to activate it based on the original
> network id (and transport id).
>> How will the eitscanner work in future when you only use the
>> multiplex?
>
> Not much different than now. EIT is independent of the channels.
>
>>> I also dislike the huge code duplication in eithelper.cpp.
>> This is caused by the different structure of the event tables and at
>> the moment I don't know if there is a better way for the integration,
>> but I will have a look at it.
>
> I had first the impression that the PremiereEventInformationTable is
> basicly an EIT but it can hold additional descriptors. Do you have docs
> for the premiere private sections and descriptors?

The only docs are sources from other projects (neutrino,vdr) that have
the epg implemented and outputs from dvbsnoop.
But it's very simple. The basic descriptors are the same. The difference
is that you have only one event per section packet with all
transmissions (descriptor 0xf2) for all feed channels stored within.

Wolfgang
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads