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

[Alan Young]

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