On Thursday 13 May 2004 20:49, Andrew de Quincey wrote: > > What frontend are you using? > > Are you using the recent CVS code, or the drivers from kernel >2.6.4? > > If so, try adding: > > "options dvb-core dvb_override_tune_delay=300 dvb_frontend_debug=1" > > to modules.conf, or wherever is appropriate and see if it does any better. > This will enable debugging, and increase the time spent whilst trying to > lock to 300ms temporarily, which might be the issue here. If this is still > unreliable, try increasing the dvb_override_tune_delay gradually until you > find one which works (if you do that is). > > Can you let me know how it goes? If you find a value that works well, I'll > add it in as the default for that frontend.
Hi guys, I figured out the problem! :) Fortunately for the linux-dvb community, it wasn't the driver's fault. It was the DVB-C broadcaster's fault. It was publicized WRONG modulation scheme used. It is using QAM_128 instead the publicized QAM_64. I discovered it by accidentally making a mistake when editing the file ~/.czap/channels.conf by hand. It was working in Windows, because the software has a scanning thing which was detecting the correct modulation (unfortunately, the modulation was printed as "3" so I could not recognize the true value). So, just as a warning, for everyone in Tampere (Finland) who are using linux-drivers to get DVB-C from "Tampereen Tietoverkko", please do not use QAM_64 for the frequency 418 MHz (as publicized). Use instead QAM_128!!! Sorry for the trouble guys, and thanks for your help! Aurelian -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
