Switching channels in kaffine on my DVB-T stick worked fine up to 2.6.39. Since upgrading to 3.0, if fails about half the time with no discernable pattern. /var/log/warn is littered with messages like these: Aug 14 16:46:56 coral kernel: [278131.974707] DiB0070 I2C write failed Aug 14 16:47:06 coral kernel: [278142.272778] dib0700: tx buffer length is larger than 4. Not supported. Aug 14 16:47:06 coral kernel: [278142.276734] DiB0070 I2C write failed Aug 14 16:48:52 coral kernel: [278248.743036] DiB0070 I2C write failed Aug 14 16:49:38 coral kernel: [278294.082043] DiB0070 I2C write failed Aug 14 16:49:42 coral kernel: [278298.805911] dib0700: tx buffer length is larger than 4. Not supported. The device in question uses the dvb-usb-dib0700-1.20.fw firmware file. lsusb output: Bus 002 Device 002: ID 2040:7070 Hauppauge Nova-T Stick 3 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2040 Hauppauge idProduct 0x7070 Nova-T Stick 3 bcdDevice 1.00 iManufacturer 1 Hauppauge iProduct 2 Nova-T Stick iSerial 3 4032310248 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered)
seeing the same with 3.0.2
these patches seemed to have improved my TerraTec T3 into working condition again: http://www.spinics.net/lists/linux-media/msg36186.html https://github.com/OpenELEC/OpenELEC.tv/blob/4c1fc081335e0ae6d7107debb0336da05200b9a4/packages/linux/patches/linux-3.0.1-060-fix_dib0700_buffer_access-0.1.patch patch applied cleanly on top of 3.0.2.
(In reply to comment #2) > these patches seemed to have improved my TerraTec T3 into working condition > again: > > http://www.spinics.net/lists/linux-media/msg36186.html > > > https://github.com/OpenELEC/OpenELEC.tv/blob/4c1fc081335e0ae6d7107debb0336da05200b9a4/packages/linux/patches/linux-3.0.1-060-fix_dib0700_buffer_access-0.1.patch > > patch applied cleanly on top of 3.0.2. This patch applied to 3.0.3 seems to indeed fix the problem. I hope this gets integrated into the stable kernel rather quickly.
i am noticing my tv channel picture just hangs at an unspecified point in time (tvheadend 2.12 -> xbmc pvr). it's usually measured in 1+ hours. stop, play cycle brings it back to life.
re comment #4: Please open a new bug for this. Patch: http://git.linuxtv.org/pb/media_tree.git/commitdiff/aeb2d456b746164a4bd19e53de0a6678ca63fcad Patch: http://git.linuxtv.org/pb/media_tree.git/commitdiff/45cbff13693d645fa5dcbba964e802e1746b2e57 Patch: http://git.linuxtv.org/pb/media_tree.git/commitdiff/45cbff13693d645fa5dcbba964e802e1746b2e57
*** This bug has been marked as a duplicate of bug 41262 ***