Luca Olivetti wrote: > > > Luca Olivetti wrote: > > Thomas Bergwinkl wrote: > > > >> Luca Olivetti wrote: > >> > > [...] > > > >>> That's what I thought too. Now, I looked into pat.c but I > >>> don't see an > >>> easy way to know when all data has been received. > >>> > >> > >> > >> I attached a patch for pat.[hc]. I hope it works. Every > time sdt.c adds > >> a new channel it triggers the patfilter > (patFilter->Trigger();), so that > >> numPmtEntries will be set to 0. So when numPmtEntries == > 'number of all > >> available entries' the scan should be complete. > > > > > > I'm testing it on hotbird. While on many transponders it > seems to work > > fine, on others after 20 seconds I don't get an end of scan > from pat.c, > > I've raised the timeout to 60 seconds. Attached is a list of all the > transponders where numPmtEntries never reached num (on hotbird). The > "---- num xx pmtIndex xx numPmtEntries" lines come from a > printf right > after the Channels.Unlock() in pat.c. > What other options do I have now? > When you try to scan these transponders with the scan utility of the dvb driver, you can see filter timeouts. For example 12034V: WARNING: filter timeout pid 0x0458 WARNING: filter timeout pid 0x0453 WARNING: filter timeout pid 0x044f WARNING: filter timeout pid 0x0459 WARNING: filter timeout pid 0x045a WARNING: filter timeout pid 0x045b WARNING: filter timeout pid 0x0452 Of course you can count this timeouts in pat.c so that numPmtEntries reaches num, but every timeout lasts 10 seconds (PMT_SCAN_TIMEOUT 10). So scanning 12034V lasts more than 70 seconds! I think to speed up the channel scan it would be better if the plugin set the filters by itself. I tried to extend the channelscan plugin to do this. Scanning transponders is really fast, but there is still a problem that on some transponders many newly found channels get no pids. But I think it is a promising attempt and I hope I can figure out where the remaining problems are. Thomas
