Soeren Moch wrote: >> mt2060 I2C read failed >> >> output in dmesg, and it fails to stream the TS. >> >> Looking at the front end status it never seems static, sometimes I get: >> >> Signal, Lock, Carrier, VITERBI, Sync, >> >> which all looks good. but other times I only get: >> >> Signal, Lock, Carrier, Sync >> or >> Carrier, VITERBI >> > > As I can see the dib0700 USB bridge in this stick deactivates the > I2C controller during data streaming, so all I2C accesses to mt2060 > (tuner) and dib7000pc (dvb-t demodulator) fail. Therefore you get > "I2C read fails" messages from mt2060 and uninitialized (random) data > for the frontend (dib7000pc) status. > Unfortunately there seems to be no independent I2C gate control call in > the dib0700 firmware... > So.. .with this hardware restriction, having a "working" driver that behaves like the other devices is going to be hard? Could a fix for this be to ensure that in the driver if a tune request is sent, the driver stops streaming, tunes, then starts again? At the same time the front end status could be cached from just before streaming is started and this cached data returned when requested, rather than going to the device itself? Both of these seem a bit like a "hack" to me, but seem like they would bring the driver closer to behaving the way apps like VDR expect. If there is not way of accessing the real data, then at least a cached version from before streaming was started would provide some data. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
