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.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.