[mythtv-users] [CVS: Jul 23/24] Jump Ahead causes video freeze -- new vsync code?

[John Patrick Poet]

John Patrick Poet wrote:

> Doug Larrick wrote:
>
>> John Patrick Poet wrote:
>>
>>>
>>> When using the 23Jul04 CVS version of myth, I can Jump around in a 
>>> show and it works just fine.
>>>
>>> As of the 24Jul04 CVS version of myth, Jumping around in a show will 
>>> frequently cause the video to freeze.  When this happens the output 
>>> of mythfrontend -v playback shows:
>>>
>>> [snip]
>>> 2004-08-18 16:59:16 A/V diverged by 11389.5 frames, extending frame 
>>> to keep audio in sync
>>> [snip]
>>> 2004-08-18 16:59:35 A/V diverged by 8536.36 frames, extending frame 
>>> to keep audio in sync
>>> [snip]
>>> What is interesting, is that if I just leave it alone (not press any 
>>> keys), after about 50 seconds the video will start playing again.  
>>> Then after a few seconds of the video playing fine, mythfrontend 
>>> will terminate with an "Aborted" message.
>>
>>
>>
>> I skipped forward/back through a few recordings, and didn't have any 
>> troubles.  But from your messages, I'd guess your MPEG stream (or 
>> maybe your soundcard) is providing bad timing data immediately upon 
>> returning from a reposition.  Can you try the attached patch (against 
>> latest CVS, but the pieces should apply to any version since the 
>> vsync reimplementation) and see if it helps?  There's probably a 
>> better way to fix this, but w/o being able to reproduce it I'm clueless.
>>
>> If this doesn't work, can you make a 5-minute recording off your 
>> station available somewhere?
>>
>> -Doug
>
>
>
> Awsome!  This patch fixed the problem for me.
>
> Even after this patch, I was still getting it to "Aborted" 
> occationally, but a "make distclean;make;make install" seems to have 
> fixed that.
>
> Thank you!
>
> John
>
> P.S.  What are you using for a soundcard?  I am using an old SB Live!  
> I tried using the onboard S/PDIF, but it caused an occational crackel 
> in the sound.


I spoke too soon with regards the "Aborted" problem.  I cannot 
consistanty get it to Abort, but it still happens a lot -- probably an 
average of 1 out of every 8 times I do a 30 second JUMP.  Sometimes it 
segfaults instead of Aborts, but it is always right after doing a JUMP.  
What is really bad, is that about one out of every dozen times the 
frontend dies like this, it takes the backend with it:

QSocketDevice::writeBlock: Invalid socket
QSocketDevice::writeBlock: Invalid socket
2004-08-19 22:40:03 WriteBlock(): Aborting WriteBlock, write to socket 
failed!

I always get the above message when the frontend dies, but sometimes the 
backend will be dead after generating those messages.


It looks like the frontend is dieing in the ALSA library, from a call in 
audiooutputalsa.cpp -> getSpaceOnSoundcard -> snd_pcm_delay.  At least 
that is where it had died the time I finally got a usable stack.  Sort 
of looks like it is trying to re-initialize the audio.

I noticed that there is a new verison of ALSA available (1.0.6).  I 
was/am using 1.0.5.

I tried upgrading to 1.0.6, but that version has serious audio problems 
for me.  Any audio played with 1.0.6 cuts in/out/in/out very rapidly.  
So I went back to 1.0.5.

Next I tried switching to OSS emulation.  That seems to have fixed the 
Aborted/Segfault problem, but does not recover from the 30 second JUMPs 
as well.  With ALSA, there anywhere from zero to 1 second of stuttering 
after each JUMP.  With OSS emulation, there is anywhere from .5 to 3 
seconds of stuttering after each JUMP.  At least it does not cause the 
frontend to die, so I guess I will live with the 3 seconds of stuttering 
for now.

When I have some more time to look at it, I will try and figure out why 
the ALSA code is so fragile.  Unless David George figures it out for me ;-)

Thanks for your help, Doug.

John