Has anyone had any success using firewire to change channels rather than an IRblaster?
- 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:
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
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.
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)