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

John P Poet jppoet at gmail.com
Tue Apr 13 00:02:35 UTC 2010


On Mon, Apr 12, 2010 at 5:40 PM, Alan Young <ayoung at teleport.com> wrote:
> On 04/12/2010 04:11 PM, John P Poet wrote:
>>
>> On Mon, Apr 12, 2010 at 4:56 PM, Alan Young<ayoung at teleport.com>  wrote:
>>>
>>> The patches in the wiki are a band-aid.  They stop and restart the
>>> recorder
>>> after the channel change.  It flushes the HDPVR buffers of data and any
>>> pending data on the PC.  That's why back to back recordings end up
>>> missing
>>> several seconds.
>>
>> What those signal monitor patches do:
>>
>> 1) Tell the HD-PVR to start recording
>> 2) Test the output of the HD-PVR to see if a valid resolution is being
>> reported
>> 3) If a valid resolution is not reported, or if data is not
>> forthcoming in a timely manner then reset the HD-PVR driver and goto
>> step 1
>> 4) Tell the HD-PVR to stop recording, and continue on to the actual
>> recording process.
>>
>> As part of the process, the "state" is reported to the frontend, so
>> the user can see what is going on and abort if there is a serious
>> problem.  This also prevents the frontend from timing out, if the
>> channel change process takes more than 15 seconds.  The user can abort
>> LiveTV or try another channel at any time during the process.
>>
>> Because the signal monitor patches effectively try to briefly record
>> something, someone watching the status light on the HD-PVR would see
>> it record, stop, and then record again.  The idea is, that when the
>> actual recording process starts up, there is a very high chance that
>> the STB and HD-PVR are in a happy state.
>>
>> Even without those patches, Myth's HD-PVR recording process will issue
>> "stop recording"/"start recording" commands to the HD-PVR driver, if
>> it does not see a steady stream of data from the HD-PVR
>
> Yes, but something doesn't seem right because even when it has a valid
> resolution it still stops and starts the recorder.  I see that on back to
> back recordings of the Daily Show and The Colbert Report.  And I've tweaked
> my channel change script to remember the current channel and not change it
> if it's the same channel.  So in theory the signal should not be interrupted
> much.
>
> Looking at the old copy of the patch I have (says it's v2), i think it
> should start at m_stage==3 first to see if the signal's valid then if that's
> not true, try a start and stop.


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 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?

Feel free to play the logic there, but in my experience any speed
optimizations result in reduced reliability.

> 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 ;-)


John
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


More information about the mythtv-users mailing list