[linux-dvb] Re: AverTV DVB-T not working under Kernel 2.6.6

[Martin Kenny <marty@kennymoy.com.au>]

Hi Andrew,

> The default is 50ms, not 0. Also, it can't be 0: In that case it would spend 
> no time waiting for the frontend to lock, which definitely wouldn't work. 
> Oddly enough 50ms is the same as what the sp887x sets for the timeout so it 
> cannot be that.
Chalk that up to late night fuzziness :-)

I tried changing:

               fesettings->step_size = 166666*2;
               fesettings->max_drift = (166666*2)+1;
while leaving the delay alone, and that worked fine.

I then put dvb_frontend_debug=1 on, and started playing with the delay. From my testing, I reckon that 350ms seems to be about right (any less, and it would sometimes hunt around before settling on the original frequency).

So my final patch would be something like:
--- sp887x.c.old        2004-06-01 22:50:06.000000000 +0930
+++ sp887x.c    2004-06-02 18:03:51.154418192 +0930
@@ -636,9 +636,9 @@
       case FE_GET_TUNE_SETTINGS:
       {
               struct dvb_frontend_tune_settings* fesettings = (struct dvb_frontend_tune_settings*) arg;
-               fesettings->min_delay_ms = 50;
-               fesettings->step_size = 0;
-               fesettings->max_drift = 0;
+               fesettings->min_delay_ms = 350;
+               fesettings->step_size = 166666*2;
+               fesettings->max_drift = (166666*2)+1;
               return 0;
       }


Andrew de Quincey wrote:

> On Tuesday 01 Jun 2004 15:57, Martin Kenny wrote:
>  
> > Hi Andrew,
> >
> > I won't get a chance to play with the dvb_override_tune_delay parameter
> > until at least tomorrow (it's after midnight here), but looking at the
> > code in dvb_frontend.c, where the FE_GET_TUNE_SETTINGS ioctl is called,
> > if it's not implemented by the frontend driver, then the value has just
> > been initialized to 0. Given that 0 was working, pre 2.6.6, for people
> > with the AverTV cards, it sounds as though a good value for min_delay_ms
> > in sp887x.c would be 0.
> >    
> The default is 50ms, not 0. Also, it can't be 0: In that case it would spend 
> no time waiting for the frontend to lock, which definitely wouldn't work. 
> Oddly enough 50ms is the same as what the sp887x sets for the timeout so it 
> cannot be that.
>
> However, notice that the other two settings in the sp887's fesettings are 
> zeroed:
>                fesettings->step_size = 0;
>                fesettings->max_drift = 0;
>
> Can you try setting:
>                fesettings->step_size = 166666*2;
>                fesettings->max_drift = (166666*2)+1;
> in sp887.c (leave the delay alone) and see if that fixes it? (this will set 
> them to the default values)
>
> If it does, probably the most sensible thing is just to remove the 
> FE_GET_TUNE_SETTINGS implementation for that frontend as you have done and 
> rely on the defaults.
>
>
>