On Thu, 2012-03-15 at 23:54 -0400, Matt Berglund wrote: > Andy, > > Thanks much. No, I had the 1600 sitting in a box, and I just moved my > mobo and components [snip] into something > with more cooling so I thought I would add the 1600 into the mix. > > I checked it in windows. No luck. Windows in another machine, or Windows in the same machine? > I cleaned the machine. No luck. > > Looks like I bought a dud. As I said, it has been sitting here for a > year or more. Ohh well. Hauppauge, the manufacturer of the HVR-1600, has good customer service. When you are really sure you have a defective card from the box: give them a call, explain your situation, and see if you can get some exchange credit on a new or different unit. > I guess I'm in the market for a new card... any suggestions? I don't usually make suggestions, as that really depends on people's personal requirements. If linux support is important for you though, there is a very short list of companies that provide decent Linux support for TV capture. Buy one of their devices. Regards, Andy > Thanks for all the help, > Matt > > On Wed, Mar 14, 2012 at 9:26 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: > > Hi Matt, > > > > On Sun, 2012-03-11 at 13:45 -0400, Matt Berglund wrote: > >> Hello all, > >> > >> I'm having trouble with my 1600 listed as: Hauppauge model 74541, rev C6A3 > >> The firmware is installed. Both using yum and manually. > >> Based on the LTV wiki, it seems this is less well tested model. If > >> this is so, > > > > This model should work with the stock kernel cx18 driver and supporting > > modules, in any kernel from the past few years. > > > > (Although I must admit, I have not tested if kernel-churn outside of the > > cx18 driver in very recent 3.x kernels broke anything.) > > > >> I'll be happy to do what I can to test it. > >> > >> Subsystem: Hauppauge computer works Inc. WinTV HVR-1600 [0070:7444] > >> > >> Running Fedora 16 with 3.2.9-1.fc16.x86_64 on an MSI 790FX-GD70 with > >> an AMD 5770 and 6770 board running crossfirex/catalyst (I realize > >> this is potentially problematic but I don't think it is the cause of > >> this issue) > >> > >> I have used both the built-in drivers and now have compiled what I > >> believe are the latest linuxtv drivers, per the wiki there. > >> > >> With the following results: > >> [ 762.974890] Linux media interface: v0.10 > >> [ 762.979795] Linux video capture interface: v2.00 > >> [ 762.979804] WARNING: You are using an experimental version of the > >> media stack. > >> [ 762.979808] As the driver is backported to an older kernel, it doesn't offer > >> [ 762.979811] enough quality for its usage in production. > >> [ 762.979813] Use it with care. > > > > [snip] > > > >> [ 762.986723] cx18: Start initialization, version 1.5.1 > >> [ 762.987457] cx18-0: Initializing card 0 > >> [ 762.987460] cx18-0: Autodetected Hauppauge card > >> [ 762.993040] cx18-0: cx23418 revision 01010000 (B) > >> [ 763.227077] tveeprom 0-0050: Hauppauge model 74541, rev C6A3, serial# > >> [ 763.227080] tveeprom 0-0050: MAC address > >> [ 763.227082] tveeprom 0-0050: tuner model is TCL MFNM05-4 (idx 103, type 43) > >> [ 763.227084] tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08) > >> [ 763.227086] tveeprom 0-0050: audio processor is CX23418 (idx 38) > >> [ 763.227088] tveeprom 0-0050: decoder processor is CX23418 (idx 31) > >> [ 763.227089] tveeprom 0-0050: has radio > >> [ 763.227090] cx18-0: Autodetected Hauppauge HVR-1600 > >> [ 763.227092] cx18-0: Simultaneous Digital and Analog TV capture supported > >> [ 763.340073] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB) > >> [ 763.340076] DVB: registering new adapter (cx18) > >> [ 763.341895] s5h1409_readreg: readreg error (ret == -6) > > > > I2C bus communications between the CX23418 and CX24227(aka S5H1409) > > ATSC/QAM demodulator chip aren't working. The cx18 driver bailed out > > because of this. > > > > > > > >> [ 763.341903] cx18-0: frontend initialization failed > >> [ 763.342126] cx18-0: DVB failed to register > >> [ 763.342235] cx18-0: Registered device video32 for encoder YUV (20 x > >> 101.25 kB) > >> [ 763.342301] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes) > >> [ 763.342369] cx18-0: Registered device video24 for encoder PCM audio > >> (256 x 4.00 kB) > >> [ 763.342433] cx18-0: Registered device radio0 for encoder radio > >> [ 763.342552] cx18-0: unregister DVB > >> [ 763.343628] cx18-0: Error -1 registering devices > >> [ 763.346390] cx18-0: Error -1 on initialization > >> [ 763.346406] cx18: probe of 0000:07:07.0 failed with error -1 > >> [ 763.346427] cx18: End initialization > >> > >> This will be used to capture signals from a cable feed, both free HD > >> and SD, if possible. > > > > Yes it should be fine, but for DTV you will only be able to receive the > > unencrypted channels. > > > > > >> This happens regardless of how the drivers are installed. > >> > >> I noticed this: > >> [ 763.341895] s5h1409_readreg: readreg error (ret == -6) > >> And was wondering if this is related to the card appearing to be less > >> well known? > > > > Nope. It is likely related to your specific system hardware and/or the > > way the linux kernel sets up your motherboard's PCI chipset. > > > > Some things to do: > > > > 1. The card looks like an older model, so I'm assuming you got it used. > > Go test the card in a Windows machine and verify the digital TV side of > > the card works under that OS. > > > > > > 2. As I mentioned on IRC, the legacy conventional PCI bus is sesnitive > > to accumulations of dust. Pull *all* your PCI cards, blow the dust out > > of all the slots, reseat your cards, and test again. > > > > 3. The cx18 driver bit-bangs every bit on the I2C bus on the HVR-1600 > > with per I2C-bit PCI transactions over the PCI bus. Some PCI bridges > > may not handle this well under certain circumstances and will return > > error words on the PCI bus (0xffffffff) instead of actual data. You may > > wish to try this card in a different Linux box, with a different > > motherboard and see if the error follows the HVR-1600 or not. You could > > throw in some debug statements in cx18-io.[ch] and/or cx18-i2c.c to > > perhaps gain some insight into what is going on with your hardware. > > > > > > I am looking into converting the cx18 driver to use the CX23418 hardware > > I2C master, instead of bit-banging. That might alleviate some problems > > with PCI bridges which might behave badly with many back-to-back PCI > > accesses. The CX23418 hardware I2C master isn't very intelligent, but > > it would improve things some. My problem is that the datasheet which I > > have is poorly written in explaining how the hardware I2C master is to > > be driven, so it will take some time and experimentation. > > > > > > 4. The other I2C bus operations on the HVR-1600 (BTW, the CX23418 and > > HVR-1600 have 2 I2C buses) don't seem to have any problems: i.e. the > > EEPROM and analog tuner. It could be the CX24227 is somehow stuck in > > reset or just plain stuck. I have no GPIO pin to twiddle to reset the > > CX24227 chip. You may have some luck with ensuring there is ample power > > to power the HVR-1600 board and no ground loops. You may wish to try > > temporarily pulling all unneeded PCI/PCIe cards and drives from your > > machine, and unhook all your TV cables from the machine, and see if > > things get better. > > > >> I will enable debug and poke around a bit more, but I'm far from a > >> driver writer. > >> > >> Thanks, > >> Matt > > > > Regards, > > Andy W. > > -- 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
