Talk:Hauppauge WinTV-Aero-m - Revision history

CityK: minor edit

2012-08-27T01:38:32Z

minor edit

← Older revision		Revision as of 01:38, 27 August 2012
Line 102:		Line 102:
	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 [http://fxb.worth1000.com/entries/427478/monkeying-around HCW engineering monkey may have such pleasure].		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 [http://fxb.worth1000.com/entries/427478/monkeying-around 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.	+	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.

CityK: minor edit

2012-08-27T01:36:41Z

minor edit

← Older revision		Revision as of 01:36, 27 August 2012
Line 98:		Line 98:
	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.		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 current state of affairs ~~with~~ the media_build repo, or specifically to the Aero-m related errors I've highlighted.	+	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 [http://fxb.worth1000.com/entries/427478/monkeying-around HCW engineering monkey may have such pleasure].		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 [http://fxb.worth1000.com/entries/427478/monkeying-around 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.		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.

CityK: update

2012-08-27T01:34:33Z

update

← Older revision		Revision as of 01:34, 27 August 2012
Line 56:		Line 56:
	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 [http://www.youtube.com/watch?v=JKQ-BpO4Gzo who is going to give her the shot?] (warning: link not suitable for work or most family situations)		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 [http://www.youtube.com/watch?v=JKQ-BpO4Gzo who is going to give her the shot?] (warning: link not suitable for work or most family situations)

-	'''Quick Follow Up'''	+	'''Quick Follow Up'''<br>
	Interesting -- just looking through the old log files. I think my analysis above is on track. Seeing stuff like:		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.117457] dvb-usb: bulk message failed: -19 (26/0)
Line 94:		Line 94:
	[ 4.358297] dvb_usb: disagrees about version of symbol rc_unregister_device		[ 4.358297] dvb_usb: disagrees about version of symbol rc_unregister_device
	[ 4.358298] dvb_usb: Unknown symbol rc_unregister_device (err -22)		[ 4.358298] dvb_usb: Unknown symbol rc_unregister_device (err -22)
		+
		+	'''Update 2'''<br>
		+	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 current state of affairs with 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 [http://fxb.worth1000.com/entries/427478/monkeying-around 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.

CityK: update with info gleaned from logs

2012-08-25T19:56:22Z

update with info gleaned from logs

← Older revision		Revision as of 19:56, 25 August 2012
Line 55:		Line 55:

	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 [http://www.youtube.com/watch?v=JKQ-BpO4Gzo who is going to give her the shot?] (warning: link not suitable for work or most family situations)		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 [http://www.youtube.com/watch?v=JKQ-BpO4Gzo 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)

CityK: a bunch of minor edits

2012-08-25T19:13:56Z

a bunch of minor edits

← Older revision		Revision as of 19:13, 25 August 2012
Line 44:		Line 44:
	* 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.		* 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 [http://www.mail-archive.com/linux-media@vger.kernel.org/msg45936.html]		* M/H support was added to kernel 3.5 [http://www.mail-archive.com/linux-media@vger.kernel.org/msg45936.html]
-	* 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 v3.5	+	* the problem was first encountered, the day after updating to kernel v3.5, after a failed attempt to awaken the system from sleep (S3)
-	* 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 ~~the device~~ under Windows, but plugging it back into the Linux system revealed ~~the again~~ correct working state for the device	+	* 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)		* one day later, the device had gone south under Linux again (discovered after a cold boot)
-	* 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	+	* 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		* 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

Line 53:		Line 54:
	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?		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 it 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 register gate that I believe is being stuck, and, consequently, making it appear that the device is borked. The real question is [http://www.youtube.com/watch?v=JKQ-BpO4Gzo who is going to give her the shot?] (warning: link not suitable for work or most family situations)	+	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 [http://www.youtube.com/watch?v=JKQ-BpO4Gzo who is going to give her the shot?] (warning: link not suitable for work or most family situations)

CityK: where I think the problem may lay

2012-08-25T19:06:00Z

where I think the problem may lay

← Older revision		Revision as of 19:06, 25 August 2012
Line 39:		Line 39:
	[ 6.173318] tveeprom 14-0050: has no radio, has IR receiver, has no IR transmitter		[ 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		[ 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 [http://www.mail-archive.com/linux-media@vger.kernel.org/msg45936.html]
		+	* 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 v3.5
		+	* 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 the device under Windows, but plugging it back into the Linux system revealed the again correct working state for the device
		+	* one day later, the device had gone south under Linux again (discovered after a cold boot)
		+	* 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'''<br>
		+	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 it 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 register gate that I believe is being stuck, and, consequently, making it appear that the device is borked. The real question is [http://www.youtube.com/watch?v=JKQ-BpO4Gzo who is going to give her the shot?] (warning: link not suitable for work or most family situations)

CityK: intermediate save

2012-08-25T18:11:24Z

intermediate save

← Older revision		Revision as of 18:11, 25 August 2012
Line 1:		Line 1:
-	~~And~~ here is what dmesg gives you when its not detecting the LG DT3305:	+	'''When this device worked ... '''<br>
-	<~~pre~~>[ 2.385654] usb 1-4.3: new high-speed USB device number 5 using ehci_hcd	+	it worked great ... though that comment comes with a few caveats:
-	[ 2.471694] usb 1-4.3: New USB device found, idVendor=2040, idProduct=c61b	+	* 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)
-	[ 2.471696] usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3	+	* 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
-	[ 2.471697] usb 1-4.3: Product: WinTV Aero-M	+	* 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)
-	[ 2.471698] usb 1-4.3: Manufacturer: Hauppauge	+	* 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
-	[ 2.471699] usb 1-4.3: SerialNumber: 4034349227	+	* 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
-	[ 5.928662] dvb-usb: found a 'Hauppauge WinTV-Aero-M' in warm state.	+	* 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
-	[ 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.	+	'''Then it all went south'''<br>
-	[ 5.928696] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.	+	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).
-	[ 5.930549] DVB: registering new adapter (Hauppauge WinTV-Aero-M)	+
-	[ 6.150608] lgdt3305_read_reg: error (addr 59 reg 0001 error (ret == -121)	+	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.
-	[ 6.150613] lgdt3305_attach: error -121 on line 1144	+
-	[ 6.150614] lgdt3305_attach: unable to detect LGDT3305 hardware	+	Here is what dmesg gives you when its not detecting the LG DT3305 (along with <font color="#009000">my annotations</font>):
-	[ 6.150620] dvb-usb: no frontend was attached by 'Hauppauge WinTV-Aero-M'	+	[ 2.385654] usb 1-4.3: new high-speed USB device number 5 using ehci_hcd
-	[ 6.150893] dvb-usb: Hauppauge WinTV-Aero-M successfully initialized and connected.	+	[ 2.471694] usb 1-4.3: New USB device found, idVendor=2040, idProduct=c61b
-	[ 6.151369] mxl111sf: MxL111SF detected, v8_200 (0x18)	+	[ 2.471696] usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
-	[ 6.173309] tveeprom 14-0050: Hauppauge model 126001, rev F1G4, serial# 7817387	+	[ 2.471697] usb 1-4.3: Product: WinTV Aero-M
-	[ 6.173313] tveeprom 14-0050: MAC address is 00:0d:fe:77:48:ab	+	[ 2.471698] usb 1-4.3: Manufacturer: Hauppauge
-	[ 6.173314] tveeprom 14-0050: tuner model is MaxLinear 111 (idx 164, type 4)	+	[ 2.471699] usb 1-4.3: SerialNumber: 4034349227
-	[ 6.173316] tveeprom 14-0050: TV standards ATSC/DVB Digital (eeprom 0x80)	+	[ 5.928662] dvb-usb: found a 'Hauppauge WinTV-Aero-M' in warm state.
-	[ 6.173317] tveeprom 14-0050: audio processor is None (idx 0)	+	[ 5.928694] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
-	[ 6.173318] tveeprom 14-0050: has no radio, has IR receiver, has no IR transmitter	+	[ 5.928695] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
-	[ 6.173755] usbcore: registered new interface driver dvb_usb_mxl111sf	+	[ 5.928696] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
-	~~</pre>~~	+	[ 5.930549] DVB: registering new adapter (Hauppauge WinTV-Aero-M)
-	~~Note: that is under kernel version 3.5~~	+	<font color="#009000">[ 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'</font>
		+	[ 6.150893] dvb-usb: Hauppauge WinTV-Aero-M successfully initialized and connected.
		+	[ 6.151369] mxl111sf: MxL111SF detected, v8_200 (0x18)
		+	<font color="#009000"> ---> No LG2161 detected here either! <--- </font>
		+	[ 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

CityK: not working

2012-08-25T16:02:23Z

not working

New page

And here is what dmesg gives you when its not detecting the LG DT3305:
<pre>[ 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)
[ 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
</pre>
Note: that is under kernel version 3.5