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