On Wed, May 20, 2009 at 8:51 AM, Thierry Lelegard <thierry.lelegard@xxxxxxxxxxxxxx> wrote: > I have a few more informations. > > 1) Sorry for those who don't like top posting, but the initial > description is really too long for good readability of answers. > > 2) Since the TD-500 contains two aerial inputs instead of one for > the T-500, I plugged in two antenna cables. Then, after some tests, > I realized that this was a source of trouble: > - Two antenna cables => lots of errors (mostly garbage sometimes, > depending on the frequency). > - Top input only => still many errors but much better on both tuners. > - Bottom input only => got nothing on both tuners. > > So, from now on, I use only one antenna cable, in the top aerial input. > Maybe this could be clarified somewhere (unless it is already but I missed it). > > 3) There are still many uncorrectable errors (TS packets with "transport > error indicator" set) in the input. The amount of uncorrectable errors is > approximately 0.1% (depending on the frequency), while I do not have any > with the T-500 using the same antenna. > > These errors occurs in groups of +/- 50 consecutive packets with TEI set. > Sometimes, in the middle of packets with errors, one packet has TEI clear > but it is still erroneous (invalid PID in this context for instance). > > Note: I forgot to mention in the initial post that I set the following option: > options dvb_usb_dib0700 force_lna_activation=1 > > 4) There is apparently a minor but annoying problem in the driver concerning > the ioctl FE_GET_INFO. Its usage requires opening the frontend device in > O_RDWR mode with the TD-500. > > Comparison of T-500 vs. TD-500. > > a) After boot, before the first tuning, if we open the frontend in O_RDONLY > more, the ioctl FE_GET_INFO succeeds with the TD-500 and the T-500. > > b) While another process uses the frontend for packet reception, the ioctl > FE_GET_INFO succeeds with the TD-500 and the T-500, with frontend in > O_RDONLY mode. > > c) After the frontend has been used for packet reception but no other process > uses it any longer, the ioctl FE_GET_INFO fails with errno "no such device" > with TD-500 frontend in O_RDONLY mode. However, the ioctl FE_GET_INFO succeeds > with TD-500 frontend in O_RDWR mode. With the T-500, the ioctl FE_GET_INFO > succeeds in O_RDONLY mode. > > Using O_RDWR mode for a simple ioctl FE_GET_INFO is a problem since it > fails with "device busy" when another process is using it in O_RDWR mode > for tuning and reception, which is normal. > > I see here two inconsistencies and one "annoying feature": > - Inconsistent behaviour of ioctl FE_GET_INFO in O_RDONLY mode before and > after the first tuning. > - Incorrect error "no such device" because /dev/dvb/adapter0/frontend0 > is still there and useable in O_RDWR mode. > - Obligation to use O_RDWR mode for reading the characteristics of a device. > > -Thierry > > > >> -----Message d'origine----- >> De : linux-media-owner@xxxxxxxxxxxxxxx >> [mailto:linux-media-owner@xxxxxxxxxxxxxxx] De la part de >> Thierry Lelegard >> Envoyé : lundi 18 mai 2009 16:33 >> À : linux-media@xxxxxxxxxxxxxxx >> Objet : Hauppauge Nova-TD-500 vs. T-500 >> >> >> Hello, >> >> Like many others, I have some problems with the Hauppauge Nova-TD-500. >> >> I have been running a Fedora system with one Hauppauge Nova-T-500 >> (-T-, with one input connector, not -TD-) quite successfully >> for 2 years. >> I just built another Fedora system and ordered two T-500 but >> I actually >> received two TD-500 (the one with two input connectors). >> >> So, I now have another Fedora box with two Hauppauge Nova-TD-500 >> and it does not work quite well. >> >> The two systems (the first one with one T-500 and the second one with >> two TD-500) are running the same O/S version, same drivers, >> same firmware: >> >> - Fedora 10, up-to-date as of 2009-05-17 >> - Kernel 2.6.27.21-170.2.56.fc10.i686 >> - Latest V4L-DVB mercurial tree, same date >> - Firmware dvb-usb-dib0700-1.20.fw >> >> You will find below some outputs of dmesg, lspci, etc for the two >> systems. >> >> I use custom signal monitoring applications, no TV watching apps. >> The same application is used in both systems, same antenna input >> (roof antenna and wall socket, not the small antenna that comes >> with the cards). The application continuously reads the complete >> transport stream for analysis. From time to time, it tunes to >> some frequency, then another, etc. >> >> With the two TD-500, the 4 adapters are created under /dev/dvb. Using >> them works more or less. As far as I tested now, I do not have any >> reported error, no error message. But the input is "not good": many >> packets are corrupted. This does not happen all the time. Sometimes, >> the input is "reasonably correct" (a few packets seems incorrect) >> and sometimes it is a mess (most packets are incorrect, the result >> of the analysis report many non-existing PIDs, weird content, etc). >> >> I guess that most of you will say "most probably an application pb"... >> But the same application is working fine with: >> >> 1) Linux + Hauppauge Nova-T-500 >> 2) Linux + Hauppauge Nova-T Stick >> 3) Linux + Pinnacle PCTV stick 72e >> 4) Windows + the two above sticks >> 4) Windows + Terratec Cinergy T USB XE Rev 2 (not supported on Linux) >> >> Of course, on Windows, the input module is a custom DirectShow capture >> filter instead of Linux DVB API but the rest of the >> application is identical. >> >> Another weird behaviour: After running the monitoring application, >> ioctl (frontend_fd, FE_GET_INFO, ...) returns "No such device" errno. >> Example: >> >> 1) Run tool to get dvb device info, ie. ioctl FE_GET_INFO, right >> after system boot: >> >> /dev/dvb/adapter0 (DiBcom 7000PC, DVB-T) >> >> Status: >> >> Bit error rate ......................... 2,097,151 (0%) >> Signal/noise ratio ............................. 0 (0%) >> Signal strength ................................ 0 (0%) >> Uncorrected blocks ............................. 0 >> Frequencies: >> Current ...................................... 0 Hz >> Min ................................. 45,000,000 Hz >> Max ................................ 860,000,000 Hz >> Step .................................... 62,500 Hz >> Tolerance .................................... 0 Hz >> Spectral inversion .......................... auto >> Bandwidth .................................. 8-MHz >> FEC (high priority) .......................... 1/2 >> FEC (low priority) ........................... 1/2 >> Constellation ............................... QPSK >> Transmission mode ............................. 2K >> Guard interval .............................. 1/32 >> Hierarchy ................................... none >> >> 2) Run monitoring application. OK, with corrupted packets. >> 3) Run previous tool doing ioctl FE_GET_INFO: >> error getting info on /dev/dvb/adapter0/frontend0: No such device >> Note: this error is reported by ioctl, opening the device is OK. >> 4) # ls -l /dev/dvb/adapter0/frontend0 >> crw-rw----+ 1 tlelegard video 212, 3 2009-05-18 15:59 >> /dev/dvb/adapter0/frontend0 >> 5) Run monitoring application. OK, with corrupted packets. >> >> >> Is there any new development regarding TD-500 ? >> Any test I could make ? >> >> Thanks in advance for your assistance. >> -Thierry >> >> >> ----------------------------------------------------------------- >> dmesg - one T-500 >> ----------------------------------------------------------------- >> >> # dmesg | grep -i -e dvb -e dib >> dib0700: loaded with support for 9 different device-types >> dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold >> state, will try to load a firmware >> firmware: requesting dvb-usb-dib0700-1.20.fw >> dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' >> dib0700: firmware started successfully. >> dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. >> dvb-usb: will pass the complete MPEG2 transport stream to the >> software demuxer. >> DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) >> DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)... >> dvb-usb: will pass the complete MPEG2 transport stream to the >> software demuxer. >> DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) >> DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... >> dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully >> initialized and connected. >> usbcore: registered new interface driver dvb_usb_dib0700 >> # >> >> ----------------------------------------------------------------- >> dmesg - two TD-500 >> ----------------------------------------------------------------- >> >> # dmesg | grep -i -e dvb -e dib >> dib0700: loaded with support for 9 different device-types >> dvb-usb: found a 'Hauppauge Nova-TD-500 (84xxx)' in cold >> state, will try to load a firmware >> firmware: requesting dvb-usb-dib0700-1.20.fw >> dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' >> dib0700: firmware started successfully. >> dvb-usb: found a 'Hauppauge Nova-TD-500 (84xxx)' in warm state. >> dvb-usb: will pass the complete MPEG2 transport stream to the >> software demuxer. >> DVB: registering new adapter (Hauppauge Nova-TD-500 (84xxx)) >> DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... >> DiB0070: successfully identified >> dvb-usb: will pass the complete MPEG2 transport stream to the >> software demuxer. >> DVB: registering new adapter (Hauppauge Nova-TD-500 (84xxx)) >> DVB: registering adapter 1 frontend 0 (DiBcom 7000PC)... >> DiB0070: successfully identified >> input: IR-receiver inside an USB DVB receiver as >> /devices/pci0000:00/0000:00:1e.0/0000:05:04.2/usb3/3-1/input/input6 >> dvb-usb: schedule remote query interval to 50 msecs. >> dvb-usb: Hauppauge Nova-TD-500 (84xxx) successfully >> initialized and connected. >> dvb-usb: found a 'Hauppauge Nova-TD-500 (84xxx)' in cold >> state, will try to load a firmware >> firmware: requesting dvb-usb-dib0700-1.20.fw >> dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' >> dib0700: firmware started successfully. >> dvb-usb: found a 'Hauppauge Nova-TD-500 (84xxx)' in warm state. >> dvb-usb: will pass the complete MPEG2 transport stream to the >> software demuxer. >> DVB: registering new adapter (Hauppauge Nova-TD-500 (84xxx)) >> DVB: registering adapter 2 frontend 0 (DiBcom 7000PC)... >> DiB0070: successfully identified >> dvb-usb: will pass the complete MPEG2 transport stream to the >> software demuxer. >> DVB: registering new adapter (Hauppauge Nova-TD-500 (84xxx)) >> DVB: registering adapter 3 frontend 0 (DiBcom 7000PC)... >> DiB0070: successfully identified >> input: IR-receiver inside an USB DVB receiver as >> /devices/pci0000:00/0000:00:1e.0/0000:05:05.2/usb4/4-1/input/input7 >> dvb-usb: schedule remote query interval to 50 msecs. >> dvb-usb: Hauppauge Nova-TD-500 (84xxx) successfully >> initialized and connected. >> usbcore: registered new interface driver dvb_usb_dib0700 >> # >> >> ----------------------------------------------------------------- >> lspci - one T-500 >> ----------------------------------------------------------------- >> >> # lspci >> .... >> 0c:02.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI >> USB 1.1 Controller (rev 61) >> 0c:02.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI >> USB 1.1 Controller (rev 61) >> 0c:02.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) >> # >> >> ----------------------------------------------------------------- >> lspci - two TD-500 >> ----------------------------------------------------------------- >> >> # lspci >> 05:04.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI >> USB 1.1 Controller (rev 62) >> 05:04.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65) >> 05:05.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI >> USB 1.1 Controller (rev 62) >> 05:05.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65) >> # >> >> ----------------------------------------------------------------- >> lspci -vv - one T-500 >> ----------------------------------------------------------------- >> >> # lspci -vv -s 0c:02 >> 0c:02.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI >> USB 1.1 Controller (rev 61) (prog-if 00 [UHCI]) >> Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB >> 1.1 Controller >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ >> VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- >> DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 64, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 18 >> Region 4: I/O ports at bcc0 [size=32] >> Capabilities: [80] Power Management version 2 >> Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0+,D1+,D2+,D3hot+,D3cold-) >> Status: D0 PME-Enable- DSel=0 DScale=0 PME- >> Kernel driver in use: uhci_hcd >> >> 0c:02.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI >> USB 1.1 Controller (rev 61) (prog-if 00 [UHCI]) >> Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB >> 1.1 Controller >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ >> VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- >> DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 64, Cache Line Size: 64 bytes >> Interrupt: pin B routed to IRQ 19 >> Region 4: I/O ports at bce0 [size=32] >> Capabilities: [80] Power Management version 2 >> Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0+,D1+,D2+,D3hot+,D3cold-) >> Status: D0 PME-Enable- DSel=0 DScale=0 PME- >> Kernel driver in use: uhci_hcd >> >> 0c:02.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev >> 63) (prog-if 20 [EHCI]) >> Subsystem: VIA Technologies, Inc. USB 2.0 >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ >> VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- >> DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 64, Cache Line Size: 64 bytes >> Interrupt: pin C routed to IRQ 16 >> Region 0: Memory at f3afff00 (32-bit, >> non-prefetchable) [size=256] >> Capabilities: [80] Power Management version 2 >> Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0+,D1+,D2+,D3hot+,D3cold-) >> Status: D0 PME-Enable- DSel=0 DScale=0 PME- >> Kernel driver in use: ehci_hcd >> >> # >> >> ----------------------------------------------------------------- >> lspci -vv - two TD-500 >> ----------------------------------------------------------------- >> >> # lspci -vv -s 05:04 >> 05:04.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI >> USB 1.1 Controller (rev 62) (prog-if 00 [UHCI]) >> Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB >> 1.1 Controller >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ >> VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- >> DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 64, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 16 >> Region 4: I/O ports at ccc0 [size=32] >> Capabilities: [80] Power Management version 2 >> Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0+,D1+,D2+,D3hot+,D3cold-) >> Status: D0 PME-Enable- DSel=0 DScale=0 PME- >> Kernel driver in use: uhci_hcd >> >> 05:04.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev >> 65) (prog-if 20 [EHCI]) >> Subsystem: VIA Technologies, Inc. USB 2.0 >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ >> VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- >> DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 64, Cache Line Size: 64 bytes >> Interrupt: pin C routed to IRQ 18 >> Region 0: Memory at f9dffe00 (32-bit, >> non-prefetchable) [size=256] >> Capabilities: [80] Power Management version 2 >> Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0+,D1+,D2+,D3hot+,D3cold-) >> Status: D0 PME-Enable- DSel=0 DScale=0 PME- >> Kernel driver in use: ehci_hcd >> >> # >> >> ----------------------------------------------------------------- >> ls /dev/dvb - one T-500 >> ----------------------------------------------------------------- >> >> # ls -lR /dev/dvb >> /dev/dvb: >> total 0 >> drwxr-xr-x 2 root root 120 2009-05-12 15:53 adapter0 >> drwxr-xr-x 2 root root 120 2009-05-12 15:53 adapter1 >> >> /dev/dvb/adapter0: >> total 0 >> crw-rw----+ 1 tlelegard video 212, 0 2009-05-12 15:53 demux0 >> crw-rw----+ 1 tlelegard video 212, 1 2009-05-12 15:53 dvr0 >> crw-rw----+ 1 tlelegard video 212, 3 2009-05-12 15:53 frontend0 >> crw-rw----+ 1 tlelegard video 212, 2 2009-05-12 15:53 net0 >> >> /dev/dvb/adapter1: >> total 0 >> crw-rw----+ 1 tlelegard video 212, 4 2009-05-12 15:53 demux0 >> crw-rw----+ 1 tlelegard video 212, 5 2009-05-12 15:53 dvr0 >> crw-rw----+ 1 tlelegard video 212, 7 2009-05-12 15:53 frontend0 >> crw-rw----+ 1 tlelegard video 212, 6 2009-05-12 15:53 net0 >> # >> >> ----------------------------------------------------------------- >> ls /dev/dvb - two TD-500 >> ----------------------------------------------------------------- >> >> # ls -lR /dev/dvb >> /dev/dvb: >> total 0 >> drwxr-xr-x 2 root root 120 2009-05-18 15:59 adapter0 >> drwxr-xr-x 2 root root 120 2009-05-18 15:59 adapter1 >> drwxr-xr-x 2 root root 120 2009-05-18 15:59 adapter2 >> drwxr-xr-x 2 root root 120 2009-05-18 15:59 adapter3 >> >> /dev/dvb/adapter0: >> total 0 >> crw-rw----+ 1 tlelegard video 212, 0 2009-05-18 15:59 demux0 >> crw-rw----+ 1 tlelegard video 212, 1 2009-05-18 15:59 dvr0 >> crw-rw----+ 1 tlelegard video 212, 3 2009-05-18 15:59 frontend0 >> crw-rw----+ 1 tlelegard video 212, 2 2009-05-18 15:59 net0 >> >> /dev/dvb/adapter1: >> total 0 >> crw-rw----+ 1 tlelegard video 212, 4 2009-05-18 15:59 demux0 >> crw-rw----+ 1 tlelegard video 212, 5 2009-05-18 15:59 dvr0 >> crw-rw----+ 1 tlelegard video 212, 7 2009-05-18 15:59 frontend0 >> crw-rw----+ 1 tlelegard video 212, 6 2009-05-18 15:59 net0 >> >> /dev/dvb/adapter2: >> total 0 >> crw-rw----+ 1 tlelegard video 212, 8 2009-05-18 15:59 demux0 >> crw-rw----+ 1 tlelegard video 212, 9 2009-05-18 15:59 dvr0 >> crw-rw----+ 1 tlelegard video 212, 11 2009-05-18 15:59 frontend0 >> crw-rw----+ 1 tlelegard video 212, 10 2009-05-18 15:59 net0 >> >> /dev/dvb/adapter3: >> total 0 >> crw-rw----+ 1 tlelegard video 212, 12 2009-05-18 15:59 demux0 >> crw-rw----+ 1 tlelegard video 212, 13 2009-05-18 15:59 dvr0 >> crw-rw----+ 1 tlelegard video 212, 15 2009-05-18 15:59 frontend0 >> crw-rw----+ 1 tlelegard video 212, 14 2009-05-18 15:59 net0 >> # >> >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-media" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Thierry, Regarding the FE_GET_INFO failing if opening the frontend in O_RDONLY, I believe I tracked down that problem late last night. Assuming you're using the latest tip, it's a bug I exposed during the xc5000 patch series. There was a bug in the dvb_frontend logic where the fepriv->exit was not being set properly when shutting down the thread (which I fixed), however it exposed a second issue where the fepriv->exit is not cleared at the appropriate time. The flag does gets cleared automatically if you open the frontend in O_RDWR because the frontend thread gets recreated. However, if you open in O_RDONLY, the flag gets checked but it's in the incorrect state. To fix around the issue, try the following: open v4l/dvb_frontend.c then go to line 671. Right after the call to "fepriv->thread = NULL", add the following: fepriv->exit = 0; I'm going to do some more testing tonight and then submit a PULL request for the above. Really the locking scheme for shutting down the thread should probably be rethought - but the above should address the immediate edge case you are seeing. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
