Difference between revisions of "Talk:Hauppauge HD-PVR"

From MythTV Official Wiki
Jump to: navigation, search
m (Updating the the latest firmware: - Argh! Permissions!)
 
(13 intermediate revisions by 5 users not shown)
Line 105: Line 105:
  
 
I'd also like to know when it became common practice to revert edits on a ''discussion'' page which do not violate any ToS (effectively an act of '''censorship'''), to revert edits and immediately lock pages without explanation, and instead of carrying on a dialog on a user's Talk page about those reverted edits with an explanation to instead just '''''start threatening the user'''''. -- [[User:Dagmar d'Surreal|Dagmar d'Surreal]] 01:41, 27 January 2010 (UTC)
 
I'd also like to know when it became common practice to revert edits on a ''discussion'' page which do not violate any ToS (effectively an act of '''censorship'''), to revert edits and immediately lock pages without explanation, and instead of carrying on a dialog on a user's Talk page about those reverted edits with an explanation to instead just '''''start threatening the user'''''. -- [[User:Dagmar d'Surreal|Dagmar d'Surreal]] 01:41, 27 January 2010 (UTC)
 +
 +
== Using Mutiple HD-PVRs ==
 +
 +
Can I hook several (say four) of these to one machine running MythTV?  Seems like the 1212 is doing all the hard work, so it should be feasible.  Are the bandwidth requirements high enough you'd want them on separate USB controllers?
 +
 +
== Updating the the latest firmware ==
 +
 +
As of Aug. 2011, the latest firmware version 0x17 dated Jul 27 2011 05:11:32.
 +
This firmware has awful colour. It should be avoided.
 +
 +
Hauppage provides a "Windows driver for HD PVR - previous version for use with non-Windows systems" on their HD-PVR support page.
 +
which is in fact firmware version 0x15 dated Jun 17 2010 09:26:53
 +
This provides correct colour balance.
 +
 +
If it cuts out at 30-60 seconds of recording, the firmware should be installed a second time from a windows machine.
 +
 +
It is probably a bad idea to suggest the "latest firmware" if it cannot record properly.
 +
:You can get 1.6.29199 (0x16) to work by setting the picture settings as follows:
 +
:{| style="border: 1px solid gray"
 +
| brightness || = 128 (0x80) || valid range is 0–255
 +
|-
 +
| contrast  || = 64 (0x40) || valid range is 0–255
 +
|-
 +
| hue        || = 15 (0xf) || valid range is 0–30 (shown as even numbers between -30–30 in Windows)
 +
|-
 +
| saturation || = 64 (0x40) || valid range is 0–255
 +
|-
 +
| sharpness  || = 128 (0x80) || valid range is 0&ndash;255<br /><small>(I don't think that changing this does anything at all. At least not for component input.)</small>
 +
|-
 +
| colspan="4" | ''Source: Windows driver defaults''
 +
|}
 +
:ie. with <code>v4l2-ctl --set-ctrl brightness=0x80 --set-ctrl contrast=0x40 --set-ctrl hue=0xf --set-ctrl saturation=0x40 --set-ctrl sharpness=0x80</code>
 +
:The picture is actually correct when the device is first initialized, but I assume MythTV automatically tries to set the picture settings to old, bad defaults (which are still in the kernel driver). I haven't tried out 1.6.29207 (0x17) yet, but will do so fairly soon. [[User:Nhjm449|Nhjm449]] 03:45, 9 October 2011 (UTC)
 +
::I can confirm that these are also the 1.6.29207 (0x17) defaults, but it does appear that the device is no longer ignoring the driver's initial attempt at setting bad defaults. Looks like a patch is being worked on [http://patchwork.linuxtv.org/patch/8183/ here]. [[User:Nhjm449|Nhjm449]] 06:38, 29 October 2011 (UTC)
 +
:::I have confirmed that the patch above works with firmware 1.6.2933. [[User:Teapot|Teapot]] 21:16, 7 December 2011 (UTC)
 +
 +
---
 +
For others like me who scratched their head about where to put the above line, I tried to put the following v4l2-ctl line into my channel changer script so the settings would be made with every channel change. It didn't seem to work, although entering that command on a command line during a recording worked.
 +
I dropped the 'sharpness' one as it said it didn't recognize it. I also had to include the device with "-d /dev/video3" since I have another v4l2 device on /dev/video0. This seems to work with the 0x1e firmware from March 2012 (1.7something...). Hope this saves someone some time:
 +
 +
<code>/usr/bin/v4l2-ctl -d /dev/video3 --set-ctrl brightness=0x80 --set-ctrl contrast=0x40 --set-ctrl hue=0xf --set-ctrl saturation=0x40</code>
 +
 +
I'd welcome suggestions on where to put that command so it will 'stick' with channel changes.
 +
 +
[[User:Acodring|Acodring]] 01:05, 10 April 2012 (UTC)
 +
 +
Apologies for talking to myself... I'm not understanding why I can't get the above settings to stick. I put it into a separate little 'hdpvr_settings.sh' script that sleeps 10 seconds and then does the v4l2-ctl command. In the channel changer script I call the settings script with an '&' at the end of the line so it will quietly wait for mythtv to do whatever it's going to do then jump in and fix the settings.
 +
It works as expected if I call the channel change script directly from a command line but it has no effect when mythtv calls the channel changer script internally. [[User:Acodring|Acodring]] 03:17, 16 April 2012 (UTC)
 +
 +
Well, we all knew it was going to come down to permissions didn't we? I realized the mythbackend service couldn't run the script when I stopped the service (sudo service mythtv-backend stop) and ran mythbackend as myuser and it all worked as it should. I added group execute permissions to that new script (chmod g+x hdpvr_settings.sh), modified it's ownership to mythtv (chown myuser:mythtv hdpvr_settings.sh) and things started to work and make sense again.
 +
Through all this I was occasionally seeing the lirc blaster stop changing channels for me on the set top but that seems to have magically gone away as well. Things are good! [[User:Acodring|Acodring]] 21:30, 21 April 2012 (UTC)
 +
 +
---
 +
 +
== Overheating ==
 +
 +
I have found that the cause of HD-PVR hanging on my system is overheating due to lack of airflow above the board. Stability problems disappeared when the cover was removed, thermal pad under the heatsink was replaced with thermal grease (likely unnecessary step), and a slow-spinning fan was installed on top of the opened case.
 +
 +
Even though the case appears to have some kind of air vent under the transparent LCD rim, close inspection of the case shown that the only openings that connect the case with outside air are vents on the bottom. Hot air circulates above the board but does not exit, and can't transfer heat except through the plastic walls and lid. [[User:Teapot|Teapot]] 02:17, 8 December 2011 (UTC)

Latest revision as of 21:30, 21 April 2012

Has anyone had any success using firewire to change channels rather than an IRblaster?

UKDude 17-Mar-2010

Yes, firewire can be used to change the channel on some cable STBs. However the HDPVR is not a firewire device, nor does it have anything to do with changing channels over firewire. Please see FireWire#Changing_Channels_via_Firewire.

Are there seriously countermeasures being deployed this early in the game? Jeez, I'm used to at least a half-year of lag-time... Do you have any news reports or links to people complaining about this? How widespread is it?

Yashka 02:25, 1 June 2008 (UTC)


There are numerous users in the IRC channel who have been running into this for a while and have first-hand experience with their component being disabled. They're not specifically targeting the HD-PVR, but rather trying to proactively close the analog hole. Sky has begun to do so, and Freesat is updating firmware across six manufacturers to enable the UK equivalent of the broadcast flag which will allow per-program disabling of the component outputs.

Iamlindoro 20:34, 1 June 2008 (UTC)

Any updates on driver development? Maybe a link to the hg repository?

Thanks Abarbaccia 20:02, 11 June 2008 (UTC)

Alpha driver released, I've written a basic howto on compiling and installing the modules.

--Iamlindoro 16:29, 12 June 2008 (UTC)

Additional information about component output disabling in US

I've revised the section about component disabling. In the US, I don't think it is the case that cable and satellite providers are lobbying legislators. Rather the MPAA is lobbying the FCC to allow component output to be selectively disable for specific presentations. Of course the fear is that this is just a foot in the door to disable unencrypted outputs for everything, all the time. For now, however, that is not the case, and it isn't even certain that the FCC will allow it. Here's more information from Ars Technica, who spoke to representatives from the MPAA:

http://arstechnica.com/news.ars/post/20080608-mpaa-wants-to-stop-dvrs-from-recording-some-movies.html

http://arstechnica.com/news.ars/post/20080720-mpaa-dvr-blocking-about-multibillion-dollar-theft-problem.html

Also, is there a better reference that the one linked regarding UK providers? Aside from being difficult to read, and generally unprofessional, it is unclear who writes the blog and what the authors' interests represent regarding this issue. For example, near the end the author states: "Buyers should not be influenced by the loss of the component connection as we feel this should already have been implemented on the component connection and it does not take away from the more than capable Humax Foxsat set top box."

One of the early articles on the blog explains that it is published by "Domain Holdings", one of the "biggest Internet publishers in Europe."

Analog vs. digital component video

[Iamlindoro] wrote:

 The HD-PVR doesn't capture digital component video,
 it captures analog component.

OK. Seeing as both kinds exist, wouldn't it be a good idea to specify that it is analog component video then?

Also, the page says:

 Capture resolution is dependent on the source (ie 720p video with be captured as such,
 1080i as 1080i, etc.)...

So if it is capturing analog video, how is it detecting the format? Counting scan lines?

--Tmetro 06:09, 1 August 2008 (UTC)

Digital Component (YCbCr) isn't what you think it is. YCbCr is the one of two color schemes employed by HDMI (the other being RGB) in transmission. There is no such thing as three-wire digital component. This is to say, if the HD-PVR were a YCbCr capture device, it would be an HDMI capture device. It's not. Rather, the HD-PVR captures standard component signals, or YPbPr. The article (and the many many publicly available sources of information) clearly specifies that the HD-PVR is an analog capture device. When you say that a TV has Component Video inputs, there's no more need to specify them as analog inputs that you need to call your car a "gas auto."

Put as simply as possible, if the HD-PVR were a "Digital Component capture device," we would just call it an "HDMI Capture Device." Which it's not. It's a component video capture device. According to the extremely common use of this term, it is a given that it is analog component video. When you go to the store and buy a set of component cables, they don't hand you an HDMI cable (unless you visit a really clueless store). To clarify, HMDI is a type of component because the color signals are broken out onto separate pins on the connection.

real life experiences

Does anyone have any real life experiences using this device with MythTV?

I would like some more details in the following areas: - Stability (a serious problem with my current firewire capture setup) - HD/SD image quality - Mythfrontend hardware requirements for h.264 playback at HD resolutions

This is the first alternative for HD capture to the firewire method, and I am very interested in it, but cannot afford to gamble the purchase price on my own experimentation.

  • Picture quality is basically awesome. I've not had mine crash or otherwise fail yet (almost two weeks now)--heat was an issue for some of the first-run models but what they're shipping now seems to have that licked. The playback requirements are written up elsewhere practically in dozens of places on the wiki, but a 2.4 Ghz core minimum (which is probably more like 2.6Ghz when it comes to 1080) or use of VDPAU on an (ideally) nVidia 8500 GT or GT 220 for hardware accelleration of playback. With VDPAU doing the heavy lifting the CPU requirements immediately revert to "not much". -- Dagmar d'Surreal 01:51, 27 January 2010 (UTC)
  • This is my 'real life experience'. I have a Motorola DCX3200 cable box and an HD-PVR (rev E2 sticker). Using analog component and SPDIF audio to the HD-PVR. Channel change is with seperate mceusb IR blaster ($20 from Hong Kong) as the internal HD-PVR blaster tends to lock up the USB. Have all recording profiles set for 13,500bps and 20,200bps as the HD-PVR auto-adjusts its data rate to suit the quality of the source. It throttles itself back to about 3MBps on SD video, even with these fast VBR settings. AC3 audio is awesome. However there is a KILLER PROBLEM. When changing channels your script needs a >3.8 second delay in it, or else the SPDIF audio from the HD-PVR with lock-up and disappear. Added to the delay in the cable box this means that the frontend nearly always times out to an "irrecoverable recorder error" when changing channels while watching live TV. The backend changes, it will record OK (it takes about 10 seconds to sync up) but the frontend times out. I have recompiled the source after setting kShortTimeout in mythsocket.cpp to 13000 from 7000, but this has not fixed the problem. IMO this is a serious problem which will hurt anybody who seriously uses an HD-PVR installation in MythTV. I use 0.22.0+fixes23893
Luckily, I also have a dual-channel HDhomerun, so I am not totally dead in the water, but the wife does tease me every time I try to change the channel in LiveTV :(
I would appreciate ideas on what variable I should be extending.. or any patches which need to be applied...
You are not experiencing a MythTV problem, which is why the problem isn't going to get fixed in the MythTV code. Your issue is that your set top boxes initialization order of component and SPDIF makes the HD-PVR hardware itself think that a working signal has appeared on both lines several seconds before it has actually done so. As soon as the hardware reports it is prepared to record, myth attempts to do so. While it might be possible to move the pause into the myth code, it would be totally inappropriate, the proper solution is to fix the issue in firmware. Track HD-PVR firmware's closely as they have been steadily improving STB support over the past several years. Also, it's important to note that you make it sound like it is necessary for everyone to have an additional sleep in their channel changing script-- this is not the case. In fact, only a small minority with certain set top box and certain firmwares need the additional sleep.
Should I therefore put a warning in the Wiki that anybody with a Motorola DCX3200 Cable box should forget about being able to record from it with MythTV, and should use the Windoze DVR software instead? I wonder what proportion of the market Motorola has? Can you suggest a link to the improving STB support with the HD-PVR that we could use as a reference? Or perhaps we might suggest an alternative capture box to the HD-PVR? I have been reading everything which Google will retrieve, and honestly, this is the first time I have seen the STB specifically labeled as a problem, or that Hauppauge is working on such a problem. Indeed, the HD-PVR firmware version has been stable for about 6 months now. I do not doubt you are correct, but it sure sounds like the work-around would be fairly straightforward.
No, the problem is easily worked around by simply adding extra sleep, it hardly makes Myth, or the HD-PVR, unusable. The change you propose has massive timing repercussions for other parts of Myth, and thus is unlikely ever to be applied. Robbing Peter to pay Paul isn't an acceptable option when the solution until the firmware works better is so trivial. Better still, wean your loved ones off of Live TV and you'll never even know channel changes are slow.
Can you give me a clue where to add the sleep? I have the Mythbuntu source tree installed (which is a clean MythTV tree, I am told), and have managed to generate a new (signed) Mythbuntu package. Since I haven't coded C since C++ was just a dream in somebody's eye, it is tough for me to work through the MythTV source, it is tight code :) When I get the problem fixed I will be happy to post the details for others who come behind me. I note that Google brings up posts of others who have had, or are having, this problem :)
I am having the same issue with instability on channel changes. I have two HD-PVRs (firmware 1.5.6.1), one connected to a Scientific Atlanta 4340HDC set-top box, and one connected to a Scientific Atlanta 8300HD set-top box. Channel changes cause instability and/or corruption unless there is a minimum time delay of approximately 5 seconds between the channel change event (accomplished through firewire to the STB in my case) and the activation of the HD-PVR. However, adding a 5 second delay in the channel change script causes mythfrontend to fail in the same manner as described above. Note that there is no problem with the backend -- the HD-PVR units have worked reliably for weeks, and continue to work without a hitch, so long as they are provided the necessary delay between channel changes to account for the problems with the set-top boxes. With respect to patching the frontend, I don't have the time to recompile the source, and I have not experimented with it. Since the backend works fine, my solution is simply not to watch live TV until this problem is resolved. :( I agree that the problem is, technically speaking, not with MythTV, but it seems to me as though the MythTV project could easily effect a solution by providing a user-editable timeout delay for channel changes, so that the frontend will wait a little longer. I hope that there is not some philosophical objection to providing such a feature to those of us who require it. I suspect that a large proportion of future MythTV users will have HD-PVR units, and my experience confirms that this problem is NOT restricted to Motorola set-top boxes, but affects Scientific Atlanta boxes as well. -- Marten, Apr 25, 2010.
Nobody said it was only Motorola boxes. I said it was certain boxes in certain configurations, with certain firmwares. There *is* a philosophical objection to adding such a timeout. It's not appropriate to add yet another useless setting when that's not where the issue lies, and should be handled by fixing the driver, the firmware of the box, and in myth, by monitoring channel change scripts as well as with the HD-PVR signal monitor patch. Anyone complaining here should ideally not be doing so until after having applied all the patches mentioned in the wiki page (#6719, #6611). If you care about solving your problems, please make time to recompile from source. Solicitation on performance with the HD-PVR in LiveTV was requested on the lists, with little response. If people truly care to see the issues solved, the least they could do would be test patches to solve it.

Firmware issue

At this time, the only way to load firmware on the unit is to use a Windows machine. The download from the Hauppauge web site calls it a "driver", however, this is actually a Windows driver and HDPVR firmware combination upgrade. There is no way to tell what firmware is on your unit (Hauppauge has confirmed this). So, if you are having trouble with your HDPVR (i.e. audio drift or recording at 60fps rather than 59.94), the best thing to do is try to upgrade the firmware. If the stated firmware claims a particular fix and the update does not fix it, try again. Another thing to try is to find an older version of the firmware and "downgrade" to that and then try the newer firmware again. After upgrading the firmware, be sure to let Windows reboot. I believe there is further updating that occurs as Windows reboots after the firmware update (I can't confirm this, but it's better to be safe than sorry). David S Feb 18, 2010.

How is Audio Handled?

Does audio also come in over the USB connection or do you have to use the optical audio out from the device? Is the audio from the USB Dolby 5.1?

  • Audio and video are passed via USB. If you use the optical in and the signal is 5.1, so will the resulting file. Iamlindoro 16:34, 22 January 2010 (UTC)

HDMI to analog conversion needs to be on it's own page

Simply put, this information doesn't belong on this page. It needs to be changed to a link pointing to a page dedicated to that subject material.

The amount of information here about the HD-Fury is:

  • not useful to all HD PVR users
  • not required to use an HD PVR
  • sizable enough to be able to fill it's own page
  • of questionable merit in that in some regions (particularly in the US) using the device to bypass content restrictions is against the law

It being here is poor information organization.

I'd also like to know when it became common practice to revert edits on a discussion page which do not violate any ToS (effectively an act of censorship), to revert edits and immediately lock pages without explanation, and instead of carrying on a dialog on a user's Talk page about those reverted edits with an explanation to instead just start threatening the user. -- Dagmar d'Surreal 01:41, 27 January 2010 (UTC)

Using Mutiple HD-PVRs

Can I hook several (say four) of these to one machine running MythTV? Seems like the 1212 is doing all the hard work, so it should be feasible. Are the bandwidth requirements high enough you'd want them on separate USB controllers?

Updating the the latest firmware

As of Aug. 2011, the latest firmware version 0x17 dated Jul 27 2011 05:11:32. This firmware has awful colour. It should be avoided.

Hauppage provides a "Windows driver for HD PVR - previous version for use with non-Windows systems" on their HD-PVR support page. which is in fact firmware version 0x15 dated Jun 17 2010 09:26:53 This provides correct colour balance.

If it cuts out at 30-60 seconds of recording, the firmware should be installed a second time from a windows machine.

It is probably a bad idea to suggest the "latest firmware" if it cannot record properly.

You can get 1.6.29199 (0x16) to work by setting the picture settings as follows:
brightness = 128 (0x80) valid range is 0–255
contrast = 64 (0x40) valid range is 0–255
hue = 15 (0xf) valid range is 0–30 (shown as even numbers between -30–30 in Windows)
saturation = 64 (0x40) valid range is 0–255
sharpness = 128 (0x80) valid range is 0–255
(I don't think that changing this does anything at all. At least not for component input.)
Source: Windows driver defaults
ie. with v4l2-ctl --set-ctrl brightness=0x80 --set-ctrl contrast=0x40 --set-ctrl hue=0xf --set-ctrl saturation=0x40 --set-ctrl sharpness=0x80
The picture is actually correct when the device is first initialized, but I assume MythTV automatically tries to set the picture settings to old, bad defaults (which are still in the kernel driver). I haven't tried out 1.6.29207 (0x17) yet, but will do so fairly soon. Nhjm449 03:45, 9 October 2011 (UTC)
I can confirm that these are also the 1.6.29207 (0x17) defaults, but it does appear that the device is no longer ignoring the driver's initial attempt at setting bad defaults. Looks like a patch is being worked on here. Nhjm449 06:38, 29 October 2011 (UTC)
I have confirmed that the patch above works with firmware 1.6.2933. Teapot 21:16, 7 December 2011 (UTC)

--- For others like me who scratched their head about where to put the above line, I tried to put the following v4l2-ctl line into my channel changer script so the settings would be made with every channel change. It didn't seem to work, although entering that command on a command line during a recording worked. I dropped the 'sharpness' one as it said it didn't recognize it. I also had to include the device with "-d /dev/video3" since I have another v4l2 device on /dev/video0. This seems to work with the 0x1e firmware from March 2012 (1.7something...). Hope this saves someone some time:

/usr/bin/v4l2-ctl -d /dev/video3 --set-ctrl brightness=0x80 --set-ctrl contrast=0x40 --set-ctrl hue=0xf --set-ctrl saturation=0x40

I'd welcome suggestions on where to put that command so it will 'stick' with channel changes.

Acodring 01:05, 10 April 2012 (UTC)

Apologies for talking to myself... I'm not understanding why I can't get the above settings to stick. I put it into a separate little 'hdpvr_settings.sh' script that sleeps 10 seconds and then does the v4l2-ctl command. In the channel changer script I call the settings script with an '&' at the end of the line so it will quietly wait for mythtv to do whatever it's going to do then jump in and fix the settings. It works as expected if I call the channel change script directly from a command line but it has no effect when mythtv calls the channel changer script internally. Acodring 03:17, 16 April 2012 (UTC)

Well, we all knew it was going to come down to permissions didn't we? I realized the mythbackend service couldn't run the script when I stopped the service (sudo service mythtv-backend stop) and ran mythbackend as myuser and it all worked as it should. I added group execute permissions to that new script (chmod g+x hdpvr_settings.sh), modified it's ownership to mythtv (chown myuser:mythtv hdpvr_settings.sh) and things started to work and make sense again. Through all this I was occasionally seeing the lirc blaster stop changing channels for me on the set top but that seems to have magically gone away as well. Things are good! Acodring 21:30, 21 April 2012 (UTC)

---

Overheating

I have found that the cause of HD-PVR hanging on my system is overheating due to lack of airflow above the board. Stability problems disappeared when the cover was removed, thermal pad under the heatsink was replaced with thermal grease (likely unnecessary step), and a slow-spinning fan was installed on top of the opened case.

Even though the case appears to have some kind of air vent under the transparent LCD rim, close inspection of the case shown that the only openings that connect the case with outside air are vents on the bottom. Hot air circulates above the board but does not exit, and can't transfer heat except through the plastic walls and lid. Teapot 02:17, 8 December 2011 (UTC)