[mythtv-users] HD-PVR Audio Sync Issues After Channel Change

[Johnny Walker]

On Mon, Apr 12, 2010 at 11:15 PM, Alan Young <ayoung at teleport.com> wrote:
> On 04/12/2010 05:02 PM, John P Poet wrote:
>>
>> Unfortunately, that does not work.  There is a window when the HD-PVR
>> driver will return the resolution for the *previous* channel.  If it
>> doesn't try to "start recording" before testing the resolution, it
>> gets fooled into thinking everything is okay, when in fact the STB is
>> not even close to tuning the new channel yet.
>
> I think there's multiple issues going on.  And you have reminded me of
> something.
>
> A while ago when I was debugging my other problem, I did some USB sniffs of
> the HDPVR on a other OS box.  I noticed then that the USB transfers were
> occurring in 23K URBs/blocks.  The linux driver does 8K blocks.  The other
> thing I noticed is the number of URBs seemed to be less than the linux box.
> The linux driver queues up 64 8K URBs for a total of 512K or so bytes of
> buffers.  So when it stops recording it has to cancel all of those URBs and
> that was one noticeable delay source with the signal buffer patch.    I'm
> wondering also if this is why Myth still sees the prior recording.  Could
> there still be packets in a buffer or queue from the prior recording and
> that is why the prior recording is registering?
>
> And back then I did a local driver patch and setup the driver module so I
> could use modparms to specify the number  and size of the buffers.  For a
> couple of months I've been running with 4 23K buffers.  That's seems to work
> well.  But this got me thinking again that maybe it's still too much.  So
> I've changed my parms down to 4 8K buffers.  Initially, channel changing in
> live TV seems to be quick stable with that.  I need to test for a few days
> to be really sure.
>
>> I understand what you are saying, though.  The process could be
>> optimized if it *knew* that the channel had not been changed.  The
>> general paradigm in Myth, however, is to play it safe and never make
>> such an assumption.  What if the user, outside of Myth's control,
>> changed the channel on the STB?
>
> Understood.  If Myth knew how to read all the boxes to see what channel the
> box was on, we could be sure of that. :)
>
>> Feel free to play the logic there, but in my experience any speed
>> optimizations result in reduced reliability.
>
> Yep, I've seen things like that in my own testing.  I hope the driver buffer
> options may be a promising start.  I do try to stabilize the DirecTV box
> before exiting my channel change program by making the box tell me what
> channel it is on.  That way I don't exit until it thinks it's changed it's
> channel (or if it can't change I exit with a error code to tell myth there's
> a problem).  That does seem to help reduce the amount of garbage that is
> picked up by the HDPVR during the switch.
>
>>> I also have ATSC card in this box, so I can test with that too.  And if
>>> need
>>> be, I can put a PVR150 back in to test too.
>>
>> More testing the better ;-)
>
> Yep.  I still wonder.  Myth seems to have been able to quickly switch on my
> ATSC card and the PVR150 card for years without loosing so much.  It seems
> like something's missing in the HDPVR process somewhere...
>
> Alan

I hope I'm not causing a ruckus in sharing this. but my HDPVR works
great. I am aware of no problems with it.

Is there any testing or stats on my box I can contribute to assist here?

I'm running the following:

AMD Phenom(tm) II X3 705e
Bus 001 Device 002: ID 2040:4902 Hauppauge
dmesg shows this on the firmware: "hdpvr 1-1:1.0: untested firmware
version 0x12"
MythBuntu 9.10
MythBackend - branches/release-0-22-fixes [23740M] www.mythtv.org
Component Capture with Analog Stereo input.
DCX-3200 TimeWarner STB

-Johnny