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)

Update 2
Okay, in response to comments I left on the linuxtv IRC channel, Antti/Crope noted that his GSoC project changes only apply to "dvb_usb_v2", and not to the old/original "dvb_usb" (which is what is producing the errors; as seen above) and that they are likely the result of the recent file and directory structure re-organization within the media build. Ahh, good old fashioned re-orgs -- when does one not ever cause a problem? Anyway, one should expect that that will get sorted out soon enough.

On the good news front, Crope mentioned that he too has an Aero-m and that he has it coded up for dvb_usb_v2 (I look forward to testing that when I get a chance). Crope also remarked that he too has seen some of the errors I've mentioned above, though, as I wasn't actually conversing with him at the time, I'm not sure if he meant the problems I noted with the current state of affairs within the media_build repo, or specifically to the Aero-m related errors I've highlighted.

So, getting back on focus -- the Aero-m. I'm pretty confident that the device is not dead but that I just need to reinitialize some of the MaxLinear chip's registers. Hopefully debricking it at this point does not require the use of JTAG (I'm assuming the SoC has a JTAG interface). If that is the case, I simply don't have the time to do that, or experience to do that (or time to learn how to do that) so it will head back on the next train to Long Island so that a HCW engineering monkey may have such pleasure.

In the bigger picture, if my assumption is correct (drivers, both Windows and Linux, are not programming the MxL111SF correctly), everyone of these devices currently is ticking away to brick itself upon encountering certain conditions.