On 31 Jul, matthieu castet wrote: > Hi, > > >>Do you have a mt2060 ? > > > > > > To be honest I am not sure. I have an AverTV A800 which certainly > > depends on DiB3000MC. Furthermore with the new driver the module for > > mt2060 is also automatically loaded when I plug in the usb-device. > > The command lsmod of the dvb-modules gives: > > Do you see "MT2060: successfully identified" in the kernel log ? No, neither in dmesg nor in /var/log/messages. In dmesg I see after initializing the device: usb 5-8: new high speed USB device using ehci_hcd and address 5 usb 5-8: configuration #1 chosen from 1 choice dibx000_common: module license 'unspecified' taints kernel. dvb-usb: found a 'AVerMedia AverTV DVB-T USB 2.0 (A800)' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (AVerMedia AverTV DVB-T USB 2.0 (A800)). DVB: registering frontend 0 (DiBcom 3000MC/P)... input: IR-receiver inside an USB DVB receiver as /class/input/input3 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: AVerMedia AverTV DVB-T USB 2.0 (A800) successfully initialized and connected. usbcore: registered new driver dvb_usb_a800 and later when using the device I get with the new driver these kind of messages: DiB3000MC: 8K 1/32 64QAM ALPHA 1 Code Rate HP 2/3 Code Rate LP -1/0 HRCH 0 DiB3000MC: FFT_UNK 1/0 QAM_UNK ALPHA 1 Code Rate HP -1/0 Code Rate LP -1/0 HRCH 0 DiB3000MC: 8K 1/32 64QAM ALPHA 1 Code Rate HP 2/3 Code Rate LP -1/0 HRCH 0 DiB3000MC: FFT_UNK 1/0 QAM_UNK ALPHA 1 Code Rate HP -1/0 Code Rate LP -1/0 HRCH 0 I suppose some debugging messages which will be removed in the final version ? However, the module mt2060 is also automatically loaded. > > Klaus Frahm wrote: >> On 31 Jul, Sergei Haller wrote: >> >> >> I am pretty certain that have had exactly the same problem as me, only I >> classified it that one needs to get a 2nd lock immediately after the >> first one to start the video flux. I am using VLC and either I had to >> push the stop/play buttons or as another work to use "tzap -x >> <Channel-name>" directly followed VLC. I believe this should also work >> with VDR (if you retry the old driver). The workaround with tzap is (or >> was) important when I wanted to program to record something. >> See my first answer in this thread for more details and links to other >> posts in the mailing list about this issue. >> >> As with you, the new driver solves this locking problem. > That's strange : on my side, I have no such locking problem with old > driver : > > FE: DiBcom 3000P/M-C DVB-T (DVBT) > status CV | signal 0000 | snr 0001 | ber 001fffff | unc 0000ffff | > status CV | signal 0000 | snr 0001 | ber 001fffff | unc 0000ffff | > status CV | signal 0000 | snr 0001 | ber 001fffff | unc 0000ffff | > status CV | signal 0000 | snr 0001 | ber 001fffff | unc 0000ffff | > status CV | signal 0000 | snr 0001 | ber 001fffff | unc 0000ffff | > status CV | signal 0000 | snr 0001 | ber 001fffff | unc 0000ffff | > <-- channel switch > status SCVYL | signal 7b22 | snr 000d | ber 00001050 | unc 00000000 | > FE_HAS_LOCK > status SCVYL | signal 7b3d | snr 0000 | ber 00000690 | unc 00000000 | > FE_HAS_LOCK > status SCVYL | signal 7b5b | snr 0000 | ber 00000720 | unc 00000000 | > FE_HAS_LOCK > > Once I have a good lock (with the old driver), switching the channels in VLC works well, the problem is to get the first good lock. As already mentioned I had signal 0000 and snr ffff with the old driver (and no patch). When using xine this problem does not appear but this may be the way xine tries to get a lock (it may do the same as the work around, getting a 2nd lock immediately after the 1st one). The situation is identical when I only use tzap and then /dev/dvb/adapter0/dvr0 to record the flux. Using tzap only once => no video flux, using tzap twice with "-x" for the first time => video flux in dvr0. Greetings, Klaus. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
