[mythtv-users] HD-PVR: Encoding Errors Running 0.22

[Alan Young]

David Engel wrote:
> On Sat, Nov 28, 2009 at 10:30:36AM -0700, Alan Young wrote:
>> David Engel wrote:
>>> I thought everyone already knew this, but just in case...  Mythtv has
>>> a workaround for the problem for the problem when the hdpvr stops
>>> recording.  When mythtv hasn't received data in some period of time,
>>> it assumes the hdpvr stopped and restarts the recording.  If mythtv
>>> didn't do this, the recording would end at the firts gap you see, the
>>> backend would be wedged affecting later recordings and there would be
>>> a lot more unhappy hdpvr users.
>> Do you know where this timeout is at?  Maybe it needs to be
>> shortened to lessen the size of the gaps?
> 
> It's in MpegRecorder::WaitFor_HDPVR().  The timeout is currently set
> to 5 seconds.  Keep mind if you make it too short, you will create
> false positives.
> 

Thanks, David.

My cable experiment in the other thread kinda worked.  With the new cable and 
kernel I'm now seeing timeout messages like this in the log:

  usb 1-1: mythbackend timed out on ep1in len=0/8192

Which is odd cause device 1-1 is the hub not the hdpvr itself.

That's lead me into digging into the source of the unofficial .21 fixes patch 
and comparing it to what's currently in the official source.

I noticed a very interesting change in Jean Yves 49_hdpvrsupport.dpatch. 
There's a change in  DeviceReadBuffer::Poll(void) that increases the poll 
timeout that seems to point to "Error poll giving up" message.  Here's the 
change...

-        int ret = poll(&polls, 1 /*number of polls*/, 10 /*msec*/);
-        if (IsPauseRequested() || !IsOpen() || !run)
+        int ret = poll(&polls, 1 /*number of polls*/, 250 /*msec*/);

I'm going to try to increase timeout that first and see what happens.

Alan