[mythtv-users] HD-PVR issues - is there a solution?

[Don Lewis]

On 22 Feb, John P Poet wrote:
> On Tue, Feb 22, 2011 at 5:09 PM, Mark <fairlane at springcom.com> wrote:
>> I've searched the web high and low for weeks and have yet to get a
>> definitive set of answers on the HD-PVR issues as they stand.  Lots of
>> people seem to have the same issues.
>>
>> 1.  Zero byte files - usually requires a reset
> 
> 
> I get this, but very rarely.  Usually the cause (for me) is the
> channel change on my Directv STB failed for some reason.  Still trying
> to figure out why that happens, and what needs to be done about it.
> 
> 
>> 2.  Unit stops responding - always requires a reset
> 
> 
> This happens to me about once every 3 to 7 weeks.  I have been trying
> to come up with a way to "reset" the HD-PVR in software, but have not
> had any luck so far -- partially because it happens so rarely to me.

Mine used to be this reliable, but it got much worse about the time I
upgraded from Fedora 12 to Fedora 14.

I've submitted a patch so that at least mythbackend will flag this as a
recording failure so that it should at least try to reschedule the
recording instead of thinking that the recording succeeded.  In the case
of the HD-PVR, manual intervention is still required to reset the box.
<http://ubuntuforums.org/showthread.php?t=1687846>

>> 3.  Audio records at 59.94Hz, and video at 60Hz, giving a sync issue over
>> time.  Some people change firmware to fix it, only to return to the same
>> state.  Is this a firmware issue or a myth issue?  Who knows?
> 
> 
> I believe this is very STB specific.  For example. people on DISH seem
> to have this problem, but I don't.
> 
> 
>> I'd like to try and collect all this information in one place / thread to
>> give folks out there struggling with the same issues a place to get
>> answers.  There's got to be a fair amount of people who've experienced
>> these issues.  Let them come forth and share experiences!
>>
>> And finally, if there's no solutions to these issues, let's do what we
>> need to do to fix them.  Bug reports, traces, whatever it takes.
> 
> 
> Myth absolutely could be better about handling hardware errors.  The
> problem is that it is hard to test the error recovery when you (I)
> can't *make* the error happen.
> 
> I have two HD-PVRs.  One is very old (a rev c2) and the other is only
> about a year old.  My newer one is pretty solid.  My older one will
> occasionally stop feeding data in the middle of a recording, but Myth
> will automatically recover from that (It does result in a loss of a
> couple of seconds out of the middle of the show, though).
> 
> I have read that at least one person has seen his HD-PVR stop
> "recording" when the S/PDIF supplied audio changed from 5.1 to 2.0 (or
> visa-versa).  This can happen when the show goes to commercial and
> back.  I have not determined if that is what is happening to me, or
> not.

I ran into that problem and in my case it would happen multiple times
during the recording of commercial-free movies.  It could well be STB
and/or signal quality related.  I gave up and switched to the analog
stereo inputs and haven't had recording dropouts since.

> Possible issues that could effect some users and not others:
> 1) USB ports.  How many devices are hooked up and contending?  How
> reliable is the USB chip-set?

In my case the HD-PVR doesn't share its USB interface with any other
devices.  The keyboard, mouse, IR receiver, and UPS are on another USB
interface.  The chipset is fairly recent.

> 2) Computer speed.  Does the computer have the spare I/O cycles to
> handle and process the data from the HD-PVR?

I've got a triple core AMD CPU.  The failures often occur when only the
HD-PVR is in use and mythfrontend is idle.  The failures always occur
before the start of the recording, so I/O and the HD-PVR overheating
from extended operation should not be a factor.

> 3) STB.  How "clean" is the video/audio from the STB?  Is the STB
> responsible for any glitches?
> 4) ???
> 
> Telling the HD-PVR to "record" when the STB is sending out garbage
> (during a channel change, for example) can result in the HD-PVR
> getting confused.  This is why some people are able to reduce their
> problems by adding a sleep at the end of their channel change scripts.
>  Myth 0.24 *tries* to alleviate the need for that sleep by verifying
> the data from the HD-PVR (after a channel change) before it starts
> actually "recording" the show.  To verify the data, Myth tries to read
> from the HD-PVR and once it is able to read any data, it then queries
> the HD-PVR for the video resolution.  Once Myth is able to get a valid
> video resolution from the HD-PVR, it assumes that the STB is producing
> clean data, and allows the recording process to start.

I increased the delay in my channel change script from 4 seconds to 10
seconds.  That seems to have helped a bit.  The frequency of failures
appears to have decreased from just about daily to every two or three
days ...