[vdr] Re: [ANNOUNCE] autopid/nvod/portal patch v7

[a.share@t-online.de (Andreas Share)]

> Hi Andreas,
>
> Andreas Share wrote:
>
> > Hi Andreas,
> >
> > nice work the latest (autopid9) patch:)
> >
> > But 2 things i have seen will not work correctly. First one Direkt ond
the
> > three will be added by the patch, but these channels cannot work,
because
> > the data is wrong (12480 vertical). I could not understand how this can
> > happen....
>
> The patch only looks at the transport stream id to find the
> corresponding frequency settings. I have discovered that this is the
> wrong way. i did assume that tid meant transponder id, but it doesn't.
> transport stream id's do uniquely identify a transponder, but there can
> be more that one transport stream id for a single transponder. tid's are
> only unique withid theyr network, so nid+tid identify a transponder.
> So, what you are probably seeing there, is a case where the tansport
> stream id (tid) in the transponders.conf is wrong or even used on
> multiple transponders.
> What i have so far been able to deduce from the neutrino source and the
> dvbdrivers scan aplication is that to get the transponder, tid, nid
> mapping right, a scan on the NIT (network information table, pid: 0x00,
> section: 0x40) is needed. The NIT also contains the frequencies and
> other operation parameters of the current and other transponders. Please
> correct me if i'm wrong!


I think you are right:)
As i remember sectiond/zapit use only two or three "default" transponders to
scan the whole network, it should be posible to go the same way, an get all
other needed information from the network itself (via NIT-scanning). In this
way the transponders.conf could be build "dynamicly" and all we needed is an
"scan_defaults.conf" witch contains some base-information for each satelite,
like neutrino.

>
> > The second is sometimes vdr fail to get an correct pmt-pid at very fast
> > zapping on premiere-channels. Because i could not see any error in eit.c
to
> > get the pat, i think this must be an driver related problem. I think in
this
> > case (pmt-pid == 0x0000) we should reread the pat. I have solve this at
the
> > moment with an very dirty loop.....
........
> > very nasty sideeffect: If an service transmit no data, it takes some
time
> > bevor i  can switch zu another channel:( But i have seen no wrong
pmt-pid
> > after the second loop anymore.
>
> mh, in eit.c the PAT filter is reset immediatly after a piece of the pat
> has been received, maybe this should only happen after the pmtpid has
> been found.

Could be work....but i think a better way is to close the filter, reopen it
and try a second time to get correct data. I think this could be done very
quick in eit.c, but needed some rewrites of the eitscanner.

Andreas




-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.