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

["Ray Glendenning" <ray.glendenning@hackery.demon.co.uk>]

Hi

From: "Andreas Schultz" <aschultz@warp10.net>
To: <vdr@linuxtv.org>
Sent: Tuesday, April 08, 2003 8:52 AM
Subject: [vdr] Re: [ANNOUNCE] autopid/nvod/portal patch v7


> 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!
>
> > 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.....
> >
> > ....
> >   if (siProcessor) {
> >      siProcessor->SetCurrentTransponder(Channel->Source(),
Channel->Tid());
> >      siProcessor->SetPendingProgramID(Channel->Sid());
> >      siProcessor->SetStatus(true);
> >      for (loop; loop < 2; loop++) {
> >          if (siProcessor->Wait4PidSync()) {
> >             vPid  = siProcessor->Vpid();
> >             aPid1 = siProcessor->Apid1();
> >             aPid2 = siProcessor->Apid2();
> >             dPid1 = siProcessor->Dpid1();
> >             dPid2 = siProcessor->Dpid2();
> >             tPid  = siProcessor->Tpid();
> >             pmtPID = siProcessor->PMTPID();
> >          }
> >          if (pmtPID |= 0x0000) break;
> >          printf("looping siProcessor to %d \n", loop);
> >     }
> >   }
> >
> >   if (!pmtPID) {
> >      if (Interface) Interface->Error("No service available!");
> >   }
> >
> > ....
> >
> > 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.
>
> > I think there should be some simalary in eit.c in an (very) future
release.
>
> The next step will be to write a NIT parser. Since i do not like the way
> libdtv works and since there isn't a NIT parser in there, i'm probably
> going to steal some ideas from neutrinos sectionsd for it.
>

I believe there is a newer version of libdtv which has NIT parsing built in.
It may be worth updating VDR to use the newer version.

Ray

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



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