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

[Phil Linttell]

> Date: Tue, 22 Feb 2011 19:09:17 -0500
> From: Mark <fairlane at springcom.com>
> Subject: [mythtv-users] HD-PVR issues - is there a solution?
> To: Discussion about mythtv <mythtv-users at mythtv.org>
>
> 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
>
> 2.  Unit stops responding - always requires a reset
>
> 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'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.
>
> What can everyone share on this?
>
> Thanks
>
Hi Mark,

I understand your frustration...  I was getting 0-byte files under 0.24
occasionally (once a week or so) with Ubuntu 10.04.  A  recording would
fail at the beginning -  it, and all subsequent recordings, would fail
with 0-byte files until the HD-PVR (rev. D2 with latest firmware) was
turned off, and back on.  I'm using a SA4250HD STB on Rogers Cable, with
a six-second delay after a change attempt.  I allow the STB to float
between 480p, 720p, and 1080i output.  I build 0.24-fixes from source,
updating frequently.  (Note, my failures were at the beginning of a
recording....  not in the middle/light-on recordings that some people
are seeing.)

I was using a add-in PCI firewire card  (with a VIA VT6306 labelled
controller chip - not sure how lspci saw it) where, under 10.04 and
earlier, the firewire bus would occasionally lock-up on a channel
change.  Reloading the firewire drivers would resolve the lock-up.  I
had long-ago included in my channel change script the commands to
re-load the firewire drivers if a channel change failed - I know it kept
happening but I don't know how frequently.

When I upgraded to Ubuntu 10.10 the 0-byte problem became much worse... 
rarely making it through a day.   With 10.10 the firewire drivers
changed....  and reloading the new, ju-ju firewire drivers would no
longer resolve a "locked" firewire bus for me.  I was pulling my hair
out trying to figure out what was causing the zero-byte files. 
(Although I did not try reverting back to the old drivers.)

About two month ago I upgraded my be motherboard, to one with an
integrated firewire port (from an Asus M3N78-VM to an Asus
M4A78TD-EVO).  I HAVEN'T HAD A FAILED RECORDING SINCE.   I made no
software changes - I didn't even have to re-install the nVidia drivers
(I'm now running 260.19.36.)  No configuration changes.  No change to
the STB or HD-PVR.  From multiple daily lock-ups to none.

The most obvious/likely possible resolution of the 0-byte files was the
switch to using the integrated firewire controller (reported by lspci as
a "VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI
Controller (rev c0)", since I no longer have any firewire bus
lock-ups.   It's still a VIA 6306-series controller but I don't know
what other changes there might be between the integrated controller and
the 3-year old add-in card.  Oh, I did change the firewire cable as
well, since I was using a a mini (4-pin?) connector previously and the
new motherboard has a larger (6-pin?) connector.

There are other possible causes.... the change in motherboard came with
a change in CPU (from Athlon X2 6000 to Phenom II X3), memory (4GB DDR-2
800MHz to 8GB DDR-3 1600 MHz), video (nVidia 8200 IGP to a GTS450 PCI
Express x16 card), and a new power supply.   Of course, there's also a
new USB controller (AMD southbridge vs. nVidia southbridge).   Net
effect is I used to run with heavily loaded CPU and some swapping.... 
now no swapping, and processing power to spare.  However, the change in
Firewire still seems the most likely explanation to me.

If you're having problems with 0-byte failures at the beginning of
recording, my suggestions are:
- if you're using the HD-PVR IR blaster for channel changing, try
firewire (if your STB supports it)
- if you're using firewire, make sure you have a 6-to-10 second (depends
on STB/cable provider - whatever it takes for the HD-PVR to "lock-on" to
the STB output) delay after a channel-change in your script
- try increasing the delay in your channel-change script
- if you're using firewire, try using plugreport to see the STB is still
"there" after a failure and test whether your channel-changing script
still works independently
- if you're using firewire under ubuntu 10.10 (or another distro that
has recently switched to ju-ju drivers), you might want to try reverting
to the "old" firewire drivers
- try a different firewire card (and maybe a different cable)


Good luck!
Phil