Currently both the channelscan and the actuator plugin offer an option to scan a complete satellite by tuning to each transponder and then waiting for 10 seconds. Is it possible to get a notification when all of the transponder data has been received? (I's assume it'd take less than 10 seconds, so a complete satellite scan should be noticeably faster).
TIA
Luca Olivetti wrote:
Currently both the channelscan and the actuator plugin offer an option to scan a complete satellite by tuning to each transponder and then waiting for 10 seconds. Is it possible to get a notification when all of the transponder data has been received? (I's assume it'd take less than 10 seconds, so a complete satellite scan should be noticeably faster).
Per chance is the most suitable place doing the following test right before the end of cSdtFilter::Process in sdt.c?
if (sdt.getSectionNumber() == sdt.getLastSectionNumber()) .....
(the ..... is something to notify the device that all data has been received, but before modifying the guts of device.[ch] I'd like to be sure this is the correct place).
Bye
Luca Olivetti wrote:
Luca Olivetti wrote:
Currently both the channelscan and the actuator plugin offer an option to scan a complete satellite by tuning to each transponder and then waiting for 10 seconds. Is it possible to get a notification when all of the transponder data has been received? (I's assume it'd take less than 10 seconds, so a complete satellite scan should be noticeably faster).
Per chance is the most suitable place doing the following test right before the end of cSdtFilter::Process in sdt.c?
if (sdt.getSectionNumber() == sdt.getLastSectionNumber()) .....
(the ..... is something to notify the device that all data has been received, but before modifying the guts of device.[ch] I'd like to be sure this is the correct place).
I just couldn't wait ;-) WDYT about the attached patch?
Bye
Luca Olivetti wrote:
I just couldn't wait ;-) WDYT about the attached patch?
- if (sdt.getSectionNumber() == sdt.getLastSectionNumber()) {
endOfScan = true;//printf ("sdt, end of scan\n");}
When you have received the last section, you don't know if you really received all sections. Perhaps the section with the last sectionnumber is the one you received first. So I think you have to check if really all section were received.
Furthermore I think it is not enough to wait only for sdt data. It would be better if you also wait for pmt data (so that the scanned channels have also VPid, APid, ...). Have a look at pat.c.
Thomas
Thomas Bergwinkl wrote:
Luca Olivetti wrote:
I just couldn't wait ;-) WDYT about the attached patch?
- if (sdt.getSectionNumber() == sdt.getLastSectionNumber()) {
endOfScan = true;//printf ("sdt, end of scan\n");}When you have received the last section, you don't know if you really received all sections. Perhaps the section with the last sectionnumber is the one you received first. So I think you have to check if really all section were received.
But this should have been taken care already by the sectionSyncer.Sync at the beginning (i.e. it should get to this line only after having received all sections).
Furthermore I think it is not enough to wait only for sdt data. It would be better if you also wait for pmt data (so that the scanned channels have also VPid, APid, ...). Have a look at pat.c.
I'll look into it. What about eit.c and nit.c?
Bye
Luca Olivetti wrote:
Thomas Bergwinkl wrote:
Luca Olivetti wrote:
I just couldn't wait ;-) WDYT about the attached patch?
- if (sdt.getSectionNumber() == sdt.getLastSectionNumber()) {
endOfScan = true;//printf ("sdt, end of scan\n");}When you have received the last section, you don't know if
you really
received all sections. Perhaps the section with the last
sectionnumber
is the one you received first. So I think you have to check
if really
all section were received.
But this should have been taken care already by the sectionSyncer.Sync at the beginning (i.e. it should get to this line only after having received all sections).
Yes, you are right. I missed this line with sectionSyncer.Sync. Sorry.
Furthermore I think it is not enough to wait only for sdt
data. It would
be better if you also wait for pmt data (so that the
scanned channels
have also VPid, APid, ...). Have a look at pat.c.
I'll look into it. What about eit.c and nit.c?
eit is just for epg data (I think) so we don't need it for a channel scan. And for a fast channel scan I think it is not necessary to wait for data of nit. When you look in nit.c you can see that just transponderdata (Source, Frequency, Polarization, SymbolRate, CodeRate) will be updated. But if we have already tuned to this channel (for scanning), we already know them.
Thomas
Thomas Bergwinkl wrote:
I'll look into it. What about eit.c and nit.c?
eit is just for epg data (I think) so we don't need it for a channel scan. And for a fast channel scan I think it is not necessary to wait for data of nit. When you look in nit.c you can see that just transponderdata (Source, Frequency, Polarization, SymbolRate, CodeRate) will be updated. But if we have already tuned to this channel (for scanning), we already know them.
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.
Bye
Luca Olivetti wrote:
Thomas Bergwinkl wrote:
I'll look into it. What about eit.c and nit.c?
eit is just for epg data (I think) so we don't need it for a channel scan. And for a fast channel scan I think it is not necessary to
wait for data
of nit. When you look in nit.c you can see that just transponderdata (Source, Frequency, Polarization, SymbolRate, CodeRate)
will be updated.
But if we have already tuned to this channel (for
scanning), we already
know them.
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.
Thomas
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, while I get and end of scan almost immediately from sdt.c. This occurs mainly on sky transponders (according to lyngsat.com, e.g. 12418V, 12341V, 12616H, etc., while I was writing this 12713V and 12731H, also from sky, did work fine) but also on some others. Maybe there's something else to check, or maybe the pmt data is really taking more than 20 seconds. Btw, this isn't going to be much faster than a timed wait: some transponders are taking a few seconds, but other are taking more than 10 seconds. I hope it is more accurate though.
Bye
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?
Bye
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
Thomas Bergwinkl wrote:
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
does it mean the broadcaster is doing something wrong or is it the driver?
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!
BTW, since I added the debug printf, I noticed that while the dish is moving it's getting the pmt data from a different satellite, so in that case it will get more than num ;-) It doesn't matter for the channel scan function (the dish is not moving) but is one more thing to take care of to make vdr behave with a steerable dish. Perhaps instead of fiddling with Setup.UpdateChannels in my plugin when the dish is moving I should call sectionHandler->SetStatus(false) ... bummer, it's private :-(
I think to speed up the channel scan it would be better if the plugin set the filters by itself.
But that wouldn't solve the filter timeout problem, would it? And it means that the plugin should duplicate most of the scanning functions already presents in vdr. I hate to do that ;-)
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.
So that's no really different from using only the sdt data :-( (channel scan was really fast too)
But I think it is a promising attempt and I hope I can figure out where the remaining problems are.
Well, if you find a good solution it should be possible to apply it also in pat.c, shouldn't it?
Bye
Luca Olivetti wrote:
Thomas Bergwinkl wrote:
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
does it mean the broadcaster is doing something wrong or is it the driver?
I'm not absolutely sure. But I think the problem is that a pid for pmt is assigned in pat, but this pmt is not in the stream. So I think it's the broadcaster's fault.
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!
BTW, since I added the debug printf, I noticed that while the dish is moving it's getting the pmt data from a different satellite, so in that case it will get more than num ;-) It doesn't matter for the channel scan function (the dish is not moving) but is one more thing to take care of to make vdr behave with a steerable dish. Perhaps instead of fiddling with Setup.UpdateChannels in my plugin when the dish is moving I should call sectionHandler->SetStatus(false) ... bummer, it's private :-(
I think to speed up the channel scan it would be better if
the plugin
set the filters by itself.
But that wouldn't solve the filter timeout problem, would it? And it means that the plugin should duplicate most of the scanning functions already presents in vdr. I hate to do that ;-)
Yes, in this case the plugin has to duplicate parts of vdr. (Copy and Paste :-) ) But I think it can solve the problem with the timeout. vdr sets in pat.c the filter for pmts one by one (always only one filter for pmt is set). In the plugin I can set e.g 10 filters simultaneous.
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.
So that's no really different from using only the sdt data :-( (channel scan was really fast too)
I think I found the problem, now there are pids for almost all channels and scanning is still fast :-)
But I think it is a promising attempt and I hope I can figure out where the remaining problems are.
Well, if you find a good solution it should be possible to apply it also in pat.c, shouldn't it?
I think pat.c is allright. When scanning in the backround there is time enough to set one filter by another.
I attached a modified version of the channelscan plugin (most of filter.c is copied from sdt.c and pat.c). Perhaps you want to try it out. It works quite well, I just scanned the entire hotbird satellite in about 5 minutes (found 1358 channels).
Thomas
Thomas Bergwinkl wrote:
I attached a modified version of the channelscan plugin (most of filter.c is copied from sdt.c and pat.c). Perhaps you want to try it out. It works quite well, I just scanned the entire hotbird satellite in about 5 minutes (found 1358 channels).
Seems good: while I don't like the duplication of code, it avoids patching vdr, and it can be extended to collect statistics (new channels found/channels modified) to show at the end of the scan. I will take a look tomorrow and "steal" ;-) filter.[ch]
Bye
Thomas Bergwinkl wrote:
I attached a modified version of the channelscan plugin (most of filter.c is copied from sdt.c and pat.c). Perhaps you want to try it out. It works quite well, I just scanned the entire hotbird satellite in about 5 minutes (found 1358 channels).
Amazing, but I still have to investigate since vdr choked on restart due to many "ERROR: channel data not unique!" (note that I didn't use the channelscan plugin, I just took filter.[ch]).
Bye
Luca Olivetti wrote:
Thomas Bergwinkl wrote:
I attached a modified version of the channelscan plugin (most of filter.c is copied from sdt.c and pat.c). Perhaps you want to try it out. It works quite well, I just scanned the entire hotbird
satellite in
about 5 minutes (found 1358 channels).
Amazing, but I still have to investigate since vdr choked on restart due to many "ERROR: channel data not unique!" (note that I didn't use the channelscan plugin, I just took filter.[ch]).
I think, I found my mistake. There was also a problem with scanning transponders without tv/radio channels. The attached patch for filter.[hc] should solve these problems.
Thomas
Thomas Bergwinkl wrote:
I think, I found my mistake. There was also a problem with scanning transponders without tv/radio channels. The attached patch for filter.[hc] should solve these problems.
Added statistics and doesn't care for Setup.UpdateChannels
Bye
Luca Olivetti wrote:
Thomas Bergwinkl wrote:
I think, I found my mistake. There was also a problem with scanning transponders without tv/radio channels. The attached patch for filter.[hc] should solve these problems.
Added statistics and doesn't care for Setup.UpdateChannels
Sorry, was this a question (why filter.[hc] doesn't care for Setup.UpdateChannels) or just a info (that you do no longer care for Setup.UpdateChannels in your plugin)?
Thomas
Thomas Bergwinkl wrote:
Luca Olivetti wrote:
[...]
Added statistics and doesn't care for Setup.UpdateChannels
Sorry, was this a question (why filter.[hc] doesn't care for Setup.UpdateChannels) or just a info (that you do no longer care for Setup.UpdateChannels in your plugin)?
the latter.
Bye
-
Luca Olivetti -
Thomas Bergwinkl