Talk:Hauppauge WinTV-Aero-m

When this device worked ...
it worked great ... though that comment comes with a few caveats:

• The bulk of my Linux user experience with the device was done while under a kernel 3.4 (will expand upon the possible importance of this point in the section below these bullet pts)
• Under Linux - I tried with the built-in antenna for OTA ATSC reception, but did so only under poor testing circumstances, and never was able to detect any ATSC channels ... never got around to testing under good circumstances, nor did I ever get around to attempting such under Windows
• Under Linux, using an external antenna for OTA ATSC reception, its tuning sensitivity was great in this regard. Never got around to testing this under Windows (have no reason to believe it would have been any different then the excellent results obtained with the device while running under Linux)
• I don't have cable TV any more, so did not get around to testing this feature (under either Linux or Windows)... in any regard, the provider in my area encrypts all but a barker channel or two, and maybe a few radio stations, so it is not really worth my time to bother checking except for being academic about it
• Nearest DVB-T source is likely 5,000km away ... would have had to go {insert stereotypical broken english accent here}"back to old country"{/end sterotype} to test this feature
• Under Linux, even if you switch to a v3.5 or better kernel, currently there are no userspace tools/apps that would allow for testing ATSC-M/H reception. I never got around to testing this under Windows. In any regard, there are only one or two M/H signals currently being tested with by broadcasters in my region, so it wasn't a pressing matter

Then it all went south
Astute readers will naturally have picked up on the "when this device worked" qualifier of that last section. You can also find similar alarming statements made by others on, amongst other websites, Amazon and Newegg. You see, my device, running under kernel 3.4, was working wonderfully for OTA ATSC (for the less then 2 months that I had had it for) until that stopped working (NOT cool).

Here is my current thought: either it coincidently borked itself just a day after I updated to kernel v3.5, or there is something (programmatically) wrong with the drivers. I will assume that the users on AMZN and the egg (whom also reported that the ATSC section of the device suddenly stopped working) are Windows users and that the problem afflicting me (running under Linux) also exits there too.

Here is what dmesg gives you when its not detecting the LG DT3305 (along with my annotations):

[    2.385654] usb 1-4.3: new high-speed USB device number 5 using ehci_hcd
[    2.471694] usb 1-4.3: New USB device found, idVendor=2040, idProduct=c61b
[    2.471696] usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.471697] usb 1-4.3: Product: WinTV Aero-M
[    2.471698] usb 1-4.3: Manufacturer: Hauppauge
[    2.471699] usb 1-4.3: SerialNumber: 4034349227
[    5.928662] dvb-usb: found a 'Hauppauge WinTV-Aero-M' in warm state.
[    5.928694] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[    5.928695] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[    5.928696] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[    5.930549] DVB: registering new adapter (Hauppauge WinTV-Aero-M)
[    6.150608] lgdt3305_read_reg: error (addr 59 reg 0001 error (ret == -121)
[    6.150613] lgdt3305_attach: error -121 on line 1144
[    6.150614] lgdt3305_attach: unable to detect LGDT3305 hardware
[    6.150620] dvb-usb: no frontend was attached by 'Hauppauge WinTV-Aero-M'
[    6.150893] dvb-usb: Hauppauge WinTV-Aero-M successfully initialized and connected.
[    6.151369] mxl111sf: MxL111SF detected, v8_200 (0x18)
      ---> No LG2161 detected here either!   <---  
[    6.173309] tveeprom 14-0050: Hauppauge model 126001, rev F1G4, serial# 7817387
[    6.173313] tveeprom 14-0050: MAC address is 00:0d:fe:77:48:ab
[    6.173314] tveeprom 14-0050: tuner model is MaxLinear 111 (idx 164, type 4)
[    6.173316] tveeprom 14-0050: TV standards ATSC/DVB Digital (eeprom 0x80)
[    6.173317] tveeprom 14-0050: audio processor is None (idx 0)
[    6.173318] tveeprom 14-0050: has no radio, has IR receiver, has no IR transmitter
[    6.173755] usbcore: registered new interface driver dvb_usb_mxl111sf

Triage

• evidently the DT3305 can't be detected ... neither is the LG2161, but there is no mention of the M/H demod in the demesg output
• The MxL111SF (a multi-function SoC) provides an interface to external demodulators so that they can leverage the MaxLinear chip's built in tuner and usb bridge.
• M/H support was added to kernel 3.5 [1]
• the problem was first encountered, the day after updating to kernel v3.5, after a failed attempt to awaken the system from sleep (S3)
• I have seen reports of problems with S3 on kernel v3.5
• the first time this happened, I was able to revive the device by doing a fresh installation of it, and the corresponding WinTV software, under Windows, ... not actually sure what step reinitialized the device, as I was actually unable to detect any channels with it under Windows while doing this, but plugging it back into the Linux system revealed a correct working state for the device again
• one day later, the device had gone south under Linux again (discovered after a cold boot)
• this second time, I was able to revive the device by doing the Windows trick again ... only it required multiple installation/deinstallation/scanning under Windows (and, again, without being able to detect channels while operating under Windows) before plugging it back into Linux revealed a working device
• a day or two later, after the second resuscitation, the device suffered a third cardiac arrest under Linux ... multiple attempts with the Windows defibrillator have failed to bring it back

Early Diagnosis
Has my device taken those final few steps towards the shadowy figures in the light? Has its electrons truly passed on through to the other side, and will never return to spark life back upon my screens in this mortal coil?

While it looks grim at the moment, I actually think that there might be hope. Offhand, I'm thinking that problems with the ACPI event (sleep S3) have exposed a fundamental flaw in the programming of registers in the MxL111SF (both under Windows and Linux). Its either coincidental, or noteworthy that the 3.5 kernel added support for the M/H LG2161 demod. Investigation into how this touched upon the MxL111SF is in order, as well as to how its inclusion impacts the LGDT3305 demod, and how a S3 event might have played a part. In a sense, the MxL111SF is the gatekeeper to these two demods. And it is a MxL111SF register gate that I believe is being stuck, and, consequently, making it appear that the device is borked. The real question is who is going to give her the shot? (warning: link not suitable for work or most family situations)

Quick Follow Up Interesting -- just looking through the old log files. I think my analysis above is on track. Seeing stuff like:

[12269.117457] dvb-usb: bulk message failed: -19 (26/0)
[12269.117460] lgdt3305_read_reg: error (addr 59 reg 0002 error (ret == -121)
[12269.117461] lgdt3305_sleep: error -121 on line 573
[12269.117462] dvb-usb: bulk message failed: -19 (26/0)

and

[12286.621611] mxl111sf: error writing addr: 0x17, mask: 0x40, data: 0x00, retrying...
[12286.621613] dvb-usb: bulk message failed: -19 (2/0)

and other MxL111SF register writing errors.

Media_build (now 8 days old) doesn't help at all, as it results in a bunch of symbol related errors. (I don't think they are anything remotely related to the problem, but rather, are related to changes that Antti/Crope has been making to dvb_usb). For posterity sake, they are as follows:

[    4.358211] dvb_usb: disagrees about version of symbol dvb_dmxdev_init
[    4.358215] dvb_usb: Unknown symbol dvb_dmxdev_init (err -22)
[    4.358231] dvb_usb: disagrees about version of symbol dvb_register_adapter
[    4.358232] dvb_usb: Unknown symbol dvb_register_adapter (err -22)
[    4.358249] dvb_usb: disagrees about version of symbol rc_register_device
[    4.358250] dvb_usb: Unknown symbol rc_register_device (err -22)
[    4.358254] dvb_usb: disagrees about version of symbol dvb_net_init
[    4.358255] dvb_usb: Unknown symbol dvb_net_init (err -22)
[    4.358261] dvb_usb: disagrees about version of symbol dvb_dmxdev_release
[    4.358262] dvb_usb: Unknown symbol dvb_dmxdev_release (err -22)
[    4.358264] dvb_usb: disagrees about version of symbol rc_free_device
[    4.358265] dvb_usb: Unknown symbol rc_free_device (err -22)
[    4.358271] dvb_usb: disagrees about version of symbol dvb_frontend_detach
[    4.358272] dvb_usb: Unknown symbol dvb_frontend_detach (err -22)
[    4.358274] dvb_usb: disagrees about version of symbol dvb_net_release
[    4.358275] dvb_usb: Unknown symbol dvb_net_release (err -22)
[    4.358278] dvb_usb: disagrees about version of symbol rc_allocate_device
[    4.358279] dvb_usb: Unknown symbol rc_allocate_device (err -22)
[    4.358283] dvb_usb: disagrees about version of symbol dvb_unregister_frontend
[    4.358284] dvb_usb: Unknown symbol dvb_unregister_frontend (err -22)
[    4.358287] dvb_usb: disagrees about version of symbol dvb_register_frontend
[    4.358288] dvb_usb: Unknown symbol dvb_register_frontend (err -22)
[    4.358291] dvb_usb: disagrees about version of symbol dvb_unregister_adapter
[    4.358292] dvb_usb: Unknown symbol dvb_unregister_adapter (err -22)
[    4.358297] dvb_usb: disagrees about version of symbol rc_unregister_device
[    4.358298] dvb_usb: Unknown symbol rc_unregister_device (err -22)