Hi, I now _think_ most of the major bugs are out of the new frontend code (THUD: the sound of the next major bug appearing :)
Anyway, I've added instrumentation to help with diagnosing the remaining issues. If you enable debug on dvb_frontend, it'll print out what values were used every time a tune attempt occurs during tune or zigzag. (BTW for people who don't know, you put "options dvb_core dvb_frontend_debug=1" in /etc/modules.conf to enable debug). You'll see lines like the following in dmesg: dvb_frontend_autotune: drift:0 bending:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0 You'll likely see several of these for each tune as different combinations of parameters are tried. This is entirely normal, especially for low symbol rate channels, which often require quite a lot of seeking about to lock on. However, if tuning is _always_ slow, and you _always_ see lots of these outputs, the tuning delay _might_ be incorrect for your frontend. You can override this with the dvb_override_tune_delay module parameter.. this takes a delay in milliseconds. Each dvb_frontend_autotune attempt will sleep for at least this length of time to let the frontend lock. The default delay is 50ms. It should be noted that dvb_override_tune_delay is really only for debugging; changes to tuning delays for a particular frontend should really be incorporated back into the frontend driver in CVS (by implementing the new FE_GET_TUNING_PARAMS ioctl in the frontend driver) e.g. for the tda1004x frontend, I found I always saw: Mar 12 11:26:22 burble kernel: dvb_frontend_autotune: drift:0 bending:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0 Mar 12 11:26:23 burble kernel: dvb_frontend_autotune: drift:166667 bending:0 inversion:0 auto_step:1 auto_sub_step:0 started_auto_step:0 Mar 12 11:26:24 burble kernel: dvb_frontend_autotune: drift:-166667 bending:0 inversion:0 auto_step:1 auto_sub_step:2 started_auto_step:0 Mar 12 11:26:24 burble kernel: dvb_frontend_autotune: drift:333334 bending:0 inversion:0 auto_step:2 auto_sub_step:0 started_auto_step:0 Mar 12 11:26:25 burble kernel: dvb_frontend_autotune: drift:-333334 bending:0 inversion:0 auto_step:2 auto_sub_step:2 started_auto_step:0 Mar 12 11:26:26 burble kernel: dvb_frontend_autotune: drift:0 bending:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0 (the last message was the one when a LOCK was reported by the userspace code) In the above, it has tried the user-supplied frequency and failed to get a lock. So its then tried frequencies around that, eventually ending up locking on the orginal frequency that failed the first time! Clear indication of a timing problem (assuming the frontend code itself is correct). I have adjusted the timings for the su1278-tsa5059, tda10045, and tda10046 frontends. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.