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.
- 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 126.96.36.199), 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.
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)