[mythtv-users] Myth problem or HDPVR probmem?

[Don Lewis]

On 14 Feb, Greg Woods wrote:
> On Mon, 2011-02-14 at 12:12 -0800, Robert McNamara wrote:
> 
>> 
>> 
>> There is more than circumstantial evidence that V4L/DVB has some
>> pretty substantial issues in current Ubuntu and derivatives.  Mike is
>> unlikely to have the issue as he rolls his own distro.  While I'm sure
>> there are exceptions, many MANY of the people reporting this issue
>> tend to be using *buntu.
> 
> Fedora 14 here, and the problem has gotten much worse since I upgraded
> from Fedora 13 to 14. I don't use DVB cards, I just have two HD-PVR
> boxes. I suspect a device driver issue but I do not know how to prove it
> or what to do about it. I would have thought it was my "quirky USB chip"
> (supposedly the reason why the IR blaster on my mceusb device will not
> work) except that so many others are reporting the same issue with their
> HD-PVRs. I only know that my Myth system is so unreliable now that I
> have stopped using it for anything I really care about and gone back to
> the crappy Comcast DVR. It is really a bummer.
> 
>> The recorder code in MythTV has not changed in *any* substantial
>> fashion since well before .22.  The *only* difference of note in
>> recorder code between .23 and .24 is an update to the HDHR libs, which
>> only affects those devices.
> 
> And ironically, I am only having issues with the HD-PVR's. The HDHR is
> working fine, but unfortunately I can only get a tiny portion of what my
> wife and I like to watch that way. Comcast here is encrypting pretty
> much everything except the OTA channels. Even the local PEG channels are
> now encrypted. 

My HD-PVR got a lot less reliable when I upgraded from Fedora 12 to
Fedora 14.  Before the upgrade, my HD-PVR would only lock up once every
few weeks, now it locks up once every few recordings.  Firewire
recording is working much more reliably now, which makes the upgrade a
step up because I do much more firewire recording and only use the
HD-PVR for the channels that aren't available on firewire.

Unlike the *buntu issue, my HD-PVR locks up with the light off.

The zero byte recording problem isn't limited to the HD-PVR.  I've also
had it happen on firewire and with my HDHR.  The firewire problem can be
easily be reproduced by tuning the STB to an encrypted channel.  I ran
into this problem a lot when both of my STBs were on the same firewire
bus and a bus reset would cause both to be reset to p2p channel 0.  When
the one driving the HD-PVR was tuned to an encrypted channel, it would
hose recordings from the other STB and I'd get zero byte recordings. I'd
get zero byte recordings from the HDHR whenever Comcast decided to remap
the clear QAM channels and I tried to tune one that had been moved.

This problem is especially maddening because even though I do the
"delete and allow re-record" dance, these shows still show up in the
database as recorded, and if the recording rule is "record one showing",
I have to re-enter the rule.

For me, the problem definitely pre-dates 0.24.  I got a lot of zero byte
firewire recordings when running 0.23.  It's mostly just gotten more
annoying since the Fedora 14 upgrade.

I think part of the fix for the generic zero byte recording problem is
to change this code in TVRec::FinishedRecording():

    if (curRec->GetRecordingStatus() != rsFailed)
        curRec->SetRecordingStatus(rsRecorded);

to this:

    if (curRec->GetRecordingStatus() == rsRecording)
        curRec->SetRecordingStatus(rsRecorded);
    else if (curRec->GetRecordingStatus() != rsFailed)
        curRec->SetRecordingStatus(rsFailed);


MainServer::DoHandleStopRecording(),
MainServer::DoHandleDeleteRecording(),
and Scheduler::ChangeRecordingEnd() should also probably be modified.