On 29 Jul, Patrick Boettcher wrote: > Hi all, > > Finally I was able to prepare everything related to the MT2060 to be > committed to the main v4l-dvb repo. > > By doing that, I also took the chance to rewrite DiB3000MC/P driver and > now it is in sync with DiBcoms internal 3000MC/P drivers (+ easier to > maintain for me, latest greatest features). For me this was the first step > before adding DiB7000-demodulator drivers because it will be based on the > same mechanism: For the architecture independent parts I just use a small > perl script to translate DiBcom's code to linux-dvb kernel code. I hope > the result is, even though some small overhead is inside, acceptable. > If someone totally disagrees, please do that now, before I spend more time > on the DiB7000-driver(s) . > > I verified the new 3000mc-driver with all devices I have and it works. > However, it might be possible that I broke something. Can everyone with a > 3000P/MC-based device please test my repository > (http://linuxtv.org/hg/~pb/v4l-dvb). Next week I will ask Mauro to pull > from it to the main tree and it would be great to have some test reports > before. I have just tested (with my my AverTV A800) and up to now it works fine, even better, your modifications seem to have corrected the other problem which I reported here: http://www.linuxtv.org/pipermail/linux-dvb/2006-June/011248.html see 2nd part of this post: > I want also to mention a different (or related ????) problem with the > device: > Very often (but not always) after I get the first lock (for example > using tzap or VLC) there is no video flux and I need to get a second > lock (for example stopping tzap and starting it immediately again, or > making stop and play with VLC, or first starting tzap with the "-x" > option and then immediately starting VLC). Maybe this is related to the > fact that I have a 100% perfect DVB-Reception from an external antenna > and for example tzap gives me something like this: > tuning to 714167000 Hz > video pid 0x0078, audio pid 0x0082 > status 03 | signal bb17 | snr 0000 | ber 001fffff | unc 0000ffff | > status 1f | signal ba37 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK > status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 | FE_HAS_LOCK > status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 | FE_HAS_LOCK > status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 | FE_HAS_LOCK > this shows a signal of "0" but the signal is in reality maximal at 100% > (also confirmed with another DVB-tuner). VLC gives the same information > about 0 signal in its output. Now with the new version, I get the video flux already for the first lock as it should be and I do no longer need to make "stop/play" in VLC to start the video flux or use the work around with tzap which I have described here: http://www.linuxtv.org/pipermail/linux-dvb/2006-July/011735.html I will continue to test and eventually also try with kernel version 2.6.17 and 2.6.16.13-4 from Suse 10.1 (but not immediatly). Greetings, Klaus. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
