* dibusb device with lock problems
@ 2011-04-11 9:06 linux
0 siblings, 0 replies; 6+ messages in thread
From: linux @ 2011-04-11 9:06 UTC (permalink / raw)
To: linux-media
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* dibusb device with lock problems
@ 2011-04-28 9:50 Lou
0 siblings, 0 replies; 6+ messages in thread
From: Lou @ 2011-04-28 9:50 UTC (permalink / raw)
To: linux-media; +Cc: pb, grafgrimm77, castet.matthieu
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* dibusb device with lock problems
@ 2011-04-03 18:15 Mr Tux
0 siblings, 0 replies; 6+ messages in thread
From: Mr Tux @ 2011-04-03 18:15 UTC (permalink / raw)
To: linux-media; +Cc: pb, grafgrimm77, castet.matthieu
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 690000000 Hz
video pid 0x00a0, audio pid 0x0050
status 00 | signal 1d37 | snr 0000 | ber 001fffff | unc 0000ffff |
status 1a | signal 2161 | snr 0046 | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1b | signal ffff | snr 0044 | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1b | signal ffff | snr 0046 | ber 00008a18 | unc 00000038 | FE_HAS_LOCK
status 1b | signal ffff | snr 004b | ber 00004d60 | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 003a | ber 00003ee4 | unc 00000000 | FE_HAS_LOCK
2nd consecutive test run using tzap:
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 690000000 Hz
video pid 0x00a0, audio pid 0x0050
status 02 | signal 0000 | snr 0000 | ber 001fffff | unc 0000ffff |
status 1a | signal 9bd0 | snr 0043 | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1b | signal ffff | snr 0040 | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1b | signal f4dd | snr 0044 | ber 00008754 | unc 0000002e | FE_HAS_LOCK
status 1b | signal ffff | snr 0042 | ber 000094a4 | unc 00000000 | FE_HAS_LOCK
status 1b | signal ffff | snr 003a | ber 000187e8 | unc 00000000 | FE_HAS_LOCK
3rd consecutive test run using tzap:
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 690000000 Hz
video pid 0x00a0, audio pid 0x0050
status 1e | signal 858e | snr 0058 | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1b | signal ffff | snr 004c | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1b | signal ffff | snr 0042 | ber 00005b18 | unc 0000000c | FE_HAS_LOCK
status 1b | signal ffff | snr 0044 | ber 0000697c | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 004e | ber 00005f20 | unc 00000000 | FE_HAS_LOCK
status 1b | signal ffff | snr 0055 | ber 00005f20 | unc 00000000 | FE_HAS_LOCK
status 1b | signal ffff | snr 0037 | ber 00005400 | unc 00000000 | 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* dibusb device with lock problems
@ 2011-04-02 13:45 Mr Tux
2011-04-03 15:37 ` Patrick Boettcher
0 siblings, 1 reply; 6+ messages in thread
From: Mr Tux @ 2011-04-02 13:45 UTC (permalink / raw)
To: linux-media; +Cc: patrick.boettcher, pb, grafgrimm77, castet.matthieu
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: dibusb device with lock problems
2011-04-02 13:45 Mr Tux
@ 2011-04-03 15:37 ` Patrick Boettcher
0 siblings, 0 replies; 6+ messages in thread
From: Patrick Boettcher @ 2011-04-03 15:37 UTC (permalink / raw)
To: Mr Tux; +Cc: linux-media, grafgrimm77, castet.matthieu
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* dibusb device with lock problems
@ 2011-02-09 14:21 Tuxoholic
0 siblings, 0 replies; 6+ messages in thread
From: Tuxoholic @ 2011-02-09 14:21 UTC (permalink / raw)
To: linux-media; +Cc: patrick.boettcher, pb
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:07 frontend0
crw-rw----+ 1 root video 212, 2 2011-02-09 14:07 net0
tuning with tzap -t 10 -c channels.conf channelname:
tune to [TSI1]
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/usr/share/dvb/channels.conf.dvbt'
tuning to 690000000 Hz
video pid 0x00a2, audio pid 0x0058
status 00 | signal a6f1 | snr 0027 | ber 001fffff | unc 0000ffff |
status 00 | signal ffff | snr 002d | ber 001fffff | unc 0000ffff |
status 00 | signal f4dd | snr 0026 | ber 0002e2f0 | unc 00000019 |
status 00 | signal f4dd | snr 0024 | ber 0002e370 | unc 00000000 |
status 00 | signal ffff | snr 0029 | ber 00031e7c | unc 00000000 |
status 00 | signal f4dd | snr 002c | ber 00031e7c | unc 00000000 |
status 00 | signal f4dd | snr 0021 | ber 000360f8 | unc 00000001 |
status 00 | signal f4dd | snr 0028 | ber 0003c120 | unc 00000000 |
status 00 | signal ffff | snr 0029 | ber 0003c120 | unc 00000000 |
status 00 | signal ffff | snr 001f | ber 00044144 | unc 00000000 |
status 00 | signal f4dd | snr 002a | ber 00044438 | unc 00000000 |
tune to [SF zwei]
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/usr/share/dvb/channels.conf.dvbt'
tuning to 690000000 Hz
video pid 0x00a3, audio pid 0x005c
status 00 | signal de98 | snr 002c | ber 001fffff | unc 0000ffff |
status 00 | signal f4dd | snr 002d | ber 001fffff | unc 0000ffff |
status 00 | signal f4dd | snr 001b | ber 0003e590 | unc 00000012 |
status 00 | signal f4dd | snr 0028 | ber 0003c250 | unc 00000000 |
status 00 | signal f4dd | snr 002e | ber 00037f28 | unc 00000000 |
status 00 | signal f4dd | snr 001b | ber 00037f28 | unc 00000000 |
status 00 | signal f4dd | snr 0024 | ber 0002cb2c | unc 00000000 |
status 00 | signal f4dd | snr 002b | ber 0002e0f8 | unc 00000000 |
status 00 | signal ffff | snr 002c | ber 0002e0f8 | unc 00000000 |
status 00 | signal ffff | snr 0033 | ber 00029654 | unc 00000000 |
status 00 | signal f4dd | snr 001c | ber 000284d4 | unc 00000000 |
tune to [SF 1]
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/usr/share/dvb/channels.conf.dvbt'
tuning to 690000000 Hz
video pid 0x00a0, audio pid 0x0050
status 00 | signal a6f1 | snr 002f | ber 001fffff | unc 0000ffff |
status 00 | signal f4dd | snr 0037 | ber 001fffff | unc 0000ffff |
status 00 | signal f4dd | snr 0018 | ber 0001f614 | unc 0000001d |
status 00 | signal f4dd | snr 002e | ber 0001dc94 | unc 00000000 |
status 00 | signal f4dd | snr 002d | ber 00031c94 | unc 00000000 |
status 00 | signal f4dd | snr 0016 | ber 00031c94 | unc 00000000 |
status 00 | signal f4dd | snr 002c | ber 000306e4 | unc 00000000 |
status 00 | signal f4dd | snr 002c | ber 0002c7d8 | unc 00000000 |
status 00 | signal f4dd | snr 0013 | ber 0002c7d8 | unc 00000000 |
status 00 | signal f4dd | snr 002d | ber 0002da20 | unc 00000000 |
status 00 | signal f4dd | snr 002e | ber 00024c58 | unc 00000000 |
tune to [SF info]
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/usr/share/dvb/channels.conf.dvbt'
tuning to 690000000 Hz
video pid 0x00a7, audio pid 0x0066
status 1a | signal a6f1 | snr 002c | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1b | signal ffff | snr 002d | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1b | signal f4dd | snr 002c | ber 0002912c | unc 0000002a | FE_HAS_LOCK
status 1b | signal f4dd | snr 0027 | ber 00025acc | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 0017 | ber 000263b8 | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 0013 | ber 000263b8 | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 002f | ber 0002eedc | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 002d | ber 00033ad0 | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 002c | ber 000358d4 | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 002a | ber 000358d4 | unc 00000000 | FE_HAS_LOCK
status 1b | signal f4dd | snr 0029 | ber 0003718c | unc 00000000 | FE_HAS_LOCK
tune to [SF zwei]
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/usr/share/dvb/channels.conf.dvbt'
tuning to 690000000 Hz
video pid 0x00a3, audio pid 0x005c
status 00 | signal c856 | snr 002d | ber 001fffff | unc 0000ffff |
status 00 | signal ffff | snr 002e | ber 001fffff | unc 0000ffff |
status 00 | signal f4dd | snr 0029 | ber 0003492c | unc 0000001d |
status 00 | signal f4dd | snr 001a | ber 000381c4 | unc 00000000 |
status 00 | signal f4dd | snr 0029 | ber 000369d0 | unc 00000000 |
status 00 | signal f4dd | snr 002c | ber 000369d0 | unc 00000000 |
status 00 | signal ffff | snr 0017 | ber 0003d168 | unc 00000000 |
status 00 | signal f4dd | snr 0021 | ber 0004ac10 | unc 00000000 |
status 00 | signal f4dd | snr 002c | ber 0004ac10 | unc 00000000 |
status 00 | signal f4dd | snr 0013 | ber 000697b4 | unc 0000000a |
status 00 | signal ffff | snr 0017 | ber 000752f8 | unc 00000007 |
@Patrick: Any idea what could be responsible for the unreliable locking?
The signal quality is not the best on my successful lock - I can get rid of
BER completely and improve the signal level to ffff (maximum) when I place the
device somewhere with better reception. So signal quality is not responsible
for the locking problem.
Regards, Tuxoholic
[1] http://linuxtv.org/hg/v4l-dvb/rev/671d1acc757c
[2] http://www.spinics.net/lists/linux-media/msg12532.html
[3] http://linuxtv.org/hg/v4l-dvb/rev/b9f55b663aa4
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-04-28 9:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-11 9:06 dibusb device with lock problems linux
-- strict thread matches above, loose matches on Subject: below --
2011-04-28 9:50 Lou
2011-04-03 18:15 Mr Tux
2011-04-02 13:45 Mr Tux
2011-04-03 15:37 ` Patrick Boettcher
2011-02-09 14:21 Tuxoholic
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox