Failed HD-PVR recordings

On Wed, Jul 8, 2009 at 10:01 AM, David Engel<david [at] istwok> wrote:
> On Wed, Jul 08, 2009 at 12:33:11AM -0400, Jeremy Thornhill wrote:
>> In my case, recordings seem to sporadically fail, and looking at the
>> backend log reveals that the same "Stop(): Not running. /
>> MPEGRec(/dev/video3) Error: Device error detected" stuff is coinciding
>> with the failed program start. Sometimes the recording will succeed
>> despite these errors, but it seems that failures correspond with an
>> increased number of error messages. My STB is set to always use 720P
>> output and the channel change script via firewire never has trouble.
>>
>> The failure mode in my case is the recording actually does take place,
>> but the TS stream seems to be corrupted in a way that makes it
>> unplayable with any software I've thrown at it. Trying to play back
>> the files on the mythfrontend causes a crash or a hang, and
>> mythcommflag is unable to flag them. Neither VLC nor mplayer is
>> capable of playback, refusing to even start playing. The one exception
>> to this is the image preview in mythtv, which is somehow generated
>> properly.
>
> I've always had the recorder stopping and restarting problem. Things
> seem to have gotten worse in the last month, though. Previously,
> there would be a glitch during playback when a stop/restart point was
> encoutered, but playback would usually resume. This was pretty much
> exclusively with software decoding. Now, with software decoding, the
> frontend usually segfaults when encoutering a stop/restart point.
> With, VDPAU, playback tends to continue, but it gets very stuttery.
>
> I think the apparent worsening of the problem around a month ago or so
> is due to player change, but I haven't looked into it. Another
> potential culprit is a change in the stop/restart handling in the
> recorder when John Poet's patch to handle it was incorporated.

I am guessing the reason different people have recording problems,
while others don't, has to do with their STBs, and possibly their
channel change scripts. One variable you can play with, is adding a 1
or 2 second sleep to the bottom of your channel change script. With
the code currently committed to myth trunk, a 1 second sleep is needed
in my directv script for reliable operation.

Adding a signal handler for the HD-PVR removed the need for that one
second delay in the channel change script (as well as some other
hard-coded sleeps in the code), but causes problems for those people
using IR-blasters. While I came up with a solution, it became pretty
obvious that it would not be accepted for inclusion in Myth, so I
stopped working on it.


> My current workaround for the playback failing is to restart the
> player and then immediately skip past the problem area. I do this by
> either making sure the bookmark gets save when I exit or I jumping to
> the specific minute I want.
>
>> I'm thinking (hoping?) that this is a firmware issue, and all I need
>> to do is track down a Windows box and update the thing, but it sounds
>> like your problems are very similar so I thought I'd chime in.
>
> This is mainly for Janne. What is the recommended firmware these
> days? I tried to follow the shspvr forum, but there seemed to be too
> many versions floating around and no consensus on which one to use.

Hauppauge themselves strongly recommends using the latest version. I
guess they fixed something which could brick your HD-PVR.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users"]http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users