dibusb device with lock problems
hello Patrick, Did you have the time to look into this issue? I noticed tuning is more reliable using a devel vdr (1.7.17): this vdr version seems to use a good strategy if the device fails to lock in it's first attempt. The stable vdr (1.6.0), kaffeine (1.2) and tzap still fail to lock with kernel 2.6.32/2.6.38 in most cases, if I retune the device I'll finally get the lock with tzap and kaffeine. Again I'm sending a copy of this to the people affected by this bug or involved with the introducing code change: Can you confirm/deny this sort of behaviour with your device - what device is this, and what player (version) are you using? Thanks for your cooperation. Lou @ vdr-portal -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dibusb device with lock problems
Hi list, as a follow-up to http://www.spinics.net/lists/linux-media/msg30930.html: I have the "Odys Easy TV Model X820001" (http://www.dooyoo.co.uk/tv-cards/odys-easy-tv-dvbt-usb-box/) which also is a dib3000mb device but it isn't mentioned yet in the list at http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices/Full. I recently updated from Debian Lenny (where the box worked flawlessly) to Squeeze and now I don't get any station tuned. Is there any fix in sight? Thanks and regards, Patrick -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dibusb device with lock problems
hello Patrick, On Sunday 03 April 2011 17:37:00 Patrick Boettcher wrote: > >I think this line is not normal in your case: > > dibusb: This device has the Thomson Cable onboard. Which is default. > Here's the output of dmesg in Lenny (kernel 2.6.26-1) where the tuning was fine: usb 2-1: new full speed USB device using ohci_hcd and address 3 usb 2-1: configuration #1 chosen from 1 choice usb 2-1: New USB device found, idVendor=1822, idProduct=3201 usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in cold state, will try to load a firmware firmware: requesting dvb-usb-dibusb-5.0.0.11.fw dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw' usbcore: registered new interface driver dvb_usb_dibusb_mb usb 2-1: USB disconnect, address 3 dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. usb 2-1: new full speed USB device using ohci_hcd and address 4 usb 2-1: configuration #1 chosen from 1 choice dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 16). DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device) DVB: registering frontend 0 (DiBcom 3000M-B DVB-T)... dibusb: This device has the Thomson Cable onboard. Which is default. input: IR-receiver inside an USB DVB receiver as /class/input/input5 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device successfully initialized and connected. usb 2-1: New USB device found, idVendor=1822, idProduct=3202 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1: Product: VP7041 usb 2-1: Manufacturer: TwinHan The Thomson line was there, nevertheless the locking was fine back then: 1st consecutive test run using tzap: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 69000 Hz video pid 0x00a0, audio pid 0x0050 status 00 | signal 1d37 | snr | ber 001f | unc | status 1a | signal 2161 | snr 0046 | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 0044 | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 0046 | ber 8a18 | unc 0038 | FE_HAS_LOCK status 1b | signal | snr 004b | ber 4d60 | unc | FE_HAS_LOCK status 1b | signal f4dd | snr 003a | ber 3ee4 | unc | FE_HAS_LOCK 2nd consecutive test run using tzap: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 69000 Hz video pid 0x00a0, audio pid 0x0050 status 02 | signal | snr | ber 001f | unc | status 1a | signal 9bd0 | snr 0043 | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 0040 | ber 001f | unc | FE_HAS_LOCK status 1b | signal f4dd | snr 0044 | ber 8754 | unc 002e | FE_HAS_LOCK status 1b | signal | snr 0042 | ber 94a4 | unc | FE_HAS_LOCK status 1b | signal | snr 003a | ber 000187e8 | unc | FE_HAS_LOCK 3rd consecutive test run using tzap: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 69000 Hz video pid 0x00a0, audio pid 0x0050 status 1e | signal 858e | snr 0058 | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 004c | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 0042 | ber 5b18 | unc 000c | FE_HAS_LOCK status 1b | signal | snr 0044 | ber 697c | unc | FE_HAS_LOCK status 1b | signal f4dd | snr 004e | ber 5f20 | unc | FE_HAS_LOCK status 1b | signal | snr 0055 | ber 5f20 | unc | FE_HAS_LOCK status 1b | signal | snr 0037 | ber 5400 | unc | FE_HAS_LOCK So even with a poorly aligned antenna I get some BER, but I always have the instant lock as expected. This changed with with the eeprom protection you introduced in 2.6.31, and the patch for Mario Bachmann never fixed it for my dib3000mb device. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb device with lock problems
Hi Mr Tux, On Saturday 02 April 2011 15:45:22 Mr Tux wrote: > Hi list, hello Patrick, > > A locking problem with specific dib3000mb devices is still present in > kernel 2.6.38. > > Now people upgrading from lenny to squeeze are also affected - see: [1] > > Please have a look at my previous post in [2] for a detailed description > and links to this bug's history. > > I'm sending a cc of this to the people who once where affected by this > bug or involved with the code change that introduced it. > > Anyone can confirm this is fixed/pending for his device and what > dib3000mb device he is using out of the linuxtv wiki list of 14 > dib3000mb devices [3]? > > I have 3 devices of the hama usb 1.1 series: [4], that's number 66 in the > wiki listing - they all are affected by this bug with kernels > 2.6.31 > > Thanks for some feedback. Can we fix this for good for the pending > devices? > > > [1] http://www.vdr-portal.de/index.php?page=Thread&postID=991041 In the post on vdr-portal you're showing the kernel-output of 2.6.32 I guess, do you still have the kernel output of 2.6.26 (or any before 2.6.32)? I think this line is not normal in your case: dibusb: This device has the Thomson Cable onboard. Which is default. But to be sure I need you to test. TUning the device is not needed with the old kernel, just plugging it and checking that line should be enough. -- Patrick. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dibusb device with lock problems
Hi list, hello Patrick, A locking problem with specific dib3000mb devices is still present in kernel 2.6.38. Now people upgrading from lenny to squeeze are also affected - see: [1] Please have a look at my previous post in [2] for a detailed description and links to this bug's history. I'm sending a cc of this to the people who once where affected by this bug or involved with the code change that introduced it. Anyone can confirm this is fixed/pending for his device and what dib3000mb device he is using out of the linuxtv wiki list of 14 dib3000mb devices [3]? I have 3 devices of the hama usb 1.1 series: [4], that's number 66 in the wiki listing - they all are affected by this bug with kernels > 2.6.31 Thanks for some feedback. Can we fix this for good for the pending devices? [1] http://www.vdr-portal.de/index.php?page=Thread&postID=991041 [2] http://www.spinics.net/lists/linux-media/msg28817.html [3] http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices/Full [4] http://www.hama.de/bilder/00049/abb/00049021abb.jpg -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dibusb device with lock problems
Hi list,
Hello Patrick,
About 22 months ago a patch was introduced in the dibusb tree of v4l to avoid
inappropriate/dangerous access to the device eeprom (r/w mixup) - see: [1] at
the -EOF-
This patch caused lock problems with the Twinhan Hama USB 1 series [2].
Patrick was able to track it down to inappropriate calls in dibusb_i2c_xfer
(read-without-write-i2caccess). A second patch [3] was released then, fixing
the locking problems.
Apparently I still do have problems to lock with my dibusb device: I
successfully lock 1 out of 5 times to a channel.
I use v4l-dvb rev 15160, both patches to dibusb-common.c are present. With a
small kernel printkey I was able to make sure the eeprom protection is
executed once, when I attach the device. While tuning, the xfer master
function stays in the first if condition for most of the time, switching to
the second condition while retuning or when tuning stops:
Here's the concerned code snippet from dibusb-common.c, note the printkeys:
===snip===
/*
* I2C master xfer function
*/
static int dibusb_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg msg[],int
num)
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
int i;
if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
return -EAGAIN;
for (i = 0; i < num; i++) {
/* write/read request */
if (i+1 < num && (msg[i].flags & I2C_M_RD) == 0
&& (msg[i+1].flags & I2C_M_RD)) {
printk(KERN_ERR "- hello I2C access in
cond1 \n");
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len) < 0)
break;
i++;
} else if ((msg[i].flags & I2C_M_RD) == 0) {
printk(KERN_ERR "- hello I2C access in
cond2 \n");
if (dibusb_i2c_msg(d, msg[i].addr,
msg[i].buf,msg[i].len,NULL,0) < 0)
break;
} else if (msg[i].addr != 0x50) {
printk(KERN_ERR "- hello I2C doing the eeprom
protection\n");
/* 0x50 is the address of the eeprom - we need to protect it
* from dibusb's bad i2c implementation: reads without
* writing the offset before are forbidden */
if (dibusb_i2c_msg(d, msg[i].addr, NULL, 0, msg[i].buf,
msg[i].len) < 0)
break;
}
}
mutex_unlock(&d->i2c_mutex);
return i;
}
===snap===
dmesg on device plugin-in:
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T
device' in cold state, will try to load a firmware
usb 2-4: firmware: requesting dvb-usb-dibusb-5.0.0.11.fw
dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw'
usbcore: registered new interface driver dvb_usb_dibusb_mb
usb 2-4: USB disconnect, address 3
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 2-4: new full speed USB device using ohci_hcd and address 4
usb 2-4: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T
device' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 16).
DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA
USB1.1 DVB-T device)
- hello I2C access in cond1
- hello I2C access in cond1
DVB: registering adapter 0 frontend 0 (DiBcom 3000M-B DVB-T)...
- hello I2C access in cond2
- hello I2C access in cond1
- hello I2C access in cond2
dibusb: This device has the Thomson Cable onboard. Which is default.
- hello I2C access in cond2
- hello I2C doing the eeprom protection
- hello I2C access in cond2
dvb-usb: schedule remote query interval to 150 msecs.
dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device
successfully initialized and connected.
ls -la /dev/dvb/adapter0/
drwxr-xr-x 2 root root 120 2011-02-09 14:07 .
drwxr-xr-x 3 root root 60 2011-02-09 14:07 ..
crw-rw+ 1 root video 212, 0 2011-02-09 14:07 demux0
crw-rw+ 1 root video 212, 1 2011-02-09 14:07 dvr0
crw-rw+ 1 root video 212, 3 2011-02-09 14:
