diff mbox

How to get a notification of a completed transponder scan?

Message ID 4246D5B3.8060209@ventoso.org
State New
Headers

Commit Message

Luca Olivetti March 27, 2005, 3:48 p.m. UTC 
  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

Comments

Thomas Bergwinkl March 27, 2005, 4:25 p.m. UTC | #1 
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
Luca Olivetti March 27, 2005, 4:43 p.m. UTC | #2 
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
Thomas Bergwinkl March 27, 2005, 5:03 p.m. UTC | #3 
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
Luca Olivetti March 27, 2005, 5:16 p.m. UTC | #4 
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
Thomas Bergwinkl March 27, 2005, 5:55 p.m. UTC | #5 
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
Luca Olivetti March 27, 2005, 8:12 p.m. UTC | #6 
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 March 28, 2005, 2:39 p.m. UTC | #7 
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
Thomas Bergwinkl March 28, 2005, 7:50 p.m. UTC | #8 
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
Luca Olivetti March 28, 2005, 9:16 p.m. UTC | #9 
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
Thomas Bergwinkl March 28, 2005, 10:04 p.m. UTC | #10 
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
Luca Olivetti March 28, 2005, 10:44 p.m. UTC | #11 
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
Luca Olivetti March 29, 2005, 7:32 p.m. UTC | #12 
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
Thomas Bergwinkl March 29, 2005, 8:02 p.m. UTC | #13 
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
diff mbox

Patch

--- device.c.fastscan	2005-03-27 16:08:42.978265685 +0200
+++ device.c	2005-03-27 16:15:48.696586409 +0200
@@ -489,6 +489,12 @@ 
      sectionHandler->Detach(Filter);
 }
 
+bool cDevice::EndOfScan(void)
+{
+  if (sdtFilter) return sdtFilter->EndOfScan();
+  return false;
+}
+
 bool cDevice::ProvidesSource(int Source) const
 {
   return false;
--- device.h.fastscan	2005-03-27 16:08:49.640207866 +0200
+++ device.h	2005-03-27 16:15:48.696586000 +0200
@@ -9,6 +9,7 @@ 
 
 #ifndef __DEVICE_H
 #define __DEVICE_H
+#define FASTSCAN_PATCHED
 
 #include "csa.h"
 #include "ci.h"
@@ -279,6 +280,8 @@ 
        ///< Attaches the given filter to this device.
   void Detach(cFilter *Filter);
        ///< Detaches the given filter from this device.
+  bool EndOfScan(void);     
+       ///< All sdt data received after a channel switch
 
 // Common Interface facilities:
 
--- sdt.c.fastscan	2005-03-27 16:00:37.754124228 +0200
+++ sdt.c	2005-03-27 17:39:19.497295538 +0200
@@ -18,6 +18,7 @@ 
 cSdtFilter::cSdtFilter(cPatFilter *PatFilter)
 {
   patFilter = PatFilter;
+  endOfScan = false;
   Set(0x11, 0x42);  // SDT
 }
 
@@ -25,6 +26,7 @@ 
 {
   cFilter::SetStatus(On);
   sectionSyncer.Reset();
+  endOfScan = false;
 }
 
 void cSdtFilter::Process(u_short Pid, u_char Tid, const u_char *Data, int Length)
@@ -123,4 +125,8 @@ 
          }
       }
   Channels.Unlock();
+  if (sdt.getSectionNumber() == sdt.getLastSectionNumber()) { 
+     endOfScan = true; 
+     //printf ("sdt, end of scan\n");
+     }
 }
--- sdt.h.fastscan	2005-03-27 16:01:09.309180845 +0200
+++ sdt.h	2005-03-27 16:04:09.267159174 +0200
@@ -17,10 +17,12 @@ 
 private:
   cSectionSyncer sectionSyncer;
   cPatFilter *patFilter;
+  bool endOfScan;
 protected:
   virtual void Process(u_short Pid, u_char Tid, const u_char *Data, int Length);
 public:
   cSdtFilter(cPatFilter *PatFilter);
+  bool EndOfScan(void) { return endOfScan; };
   virtual void SetStatus(bool On);
   };