Reinhard Nissl wrote:
> Hi,
>
> Klaus Schmidinger wrote:
>
>>>>> The attached patch should fix a hang (livelock) which can occur when
>>>>> moving between editing marks. Blame Timothy Baldwin if it doesn't
>>>>> work -
>>>>> he suggested it ;-)
>>>
>>>
>>>> Under which conditions do these lockups happen?
>>>> Which output device is in use (FF DVB card or some software player)?
>>>
>>>
>>> It's happened here: budget card, xine-lib.
>>
>>
>> Ah, as I suspected ;-)
>>
>> Could it be that the xine player doesn't implement
>> cDevice::Poll() the way it is supposed to?
>> My guess would be that in case of a still picture the xine player's
>> Poll() function returns immediately instead of waiting for the
>> given timeout. That would explain why everything appears to lock up.
>
>
> We've already discussed vdr-xine's Poll() implementation in this thread
> (~ 26.11.2004):
>
> vdr-1.3.15: high CPU load when showing still picture while editing cut
> marks
>
> At that time, you've decided to put Sleep() in the loop back again. But
> you've put it at a different location than it was in the previous versions.
>
> This can still lead to high cpu load when someone pauses a recording
> almost at the end. At that time, VDR has already read and sent the last
> packet to vdr-xine and is now just waiting for vdr-xine to report (via
> DeviceFlush()) that xine has played the last frame of the given data.
>
> The attached patch fixes this issue by exchanging two "if" blocks, which
> also moves the Sleep() almost to the position where is was located in
> earlier VDR versions.
>
> This patch is also part of my other dvbplayer-2/3 patch, but I've
> extracted it to get it included earlier than the other things of the
> original patches.
>
> But maybe it would be even better to move this Sleep() out of the locked
> area.
>
>> Could you please verify this?
>
>
> Well, as written in the above mentioned thread, after sending the still
> image data to xine, the fifo gets empty and therefore Poll() returns
> immediately, as data can be transfered to xine.
>
> But I do not see any special behaviour for FF cards in this code:
>
> bool cDvbDevice::Poll(cPoller &Poller, int TimeoutMs)
> {
> Poller.Add((playMode == pmAudioOnly
> || playMode == pmAudioOnlyBlack) ? fd_audio : fd_video, true);
> return Poller.Poll(TimeoutMs);
> }
>
> Is it that FF cards behave like that when a still image is shown?
> But as a Clear() is happening before sending the still image, I'd expect
> even a FF card to immediately return here in Poll().
>
>>>> I don't really see what difference this sched_yield() would make, so
>>>> I'd
>>>> like to understand this before simply throwing it in...
>>>
>>>
>>> Quoting from the mail which described the patch:
>>>
>>> | It's livelock!
>>>
>>> | The thread which executes cDvbPlayer::Action(void) (in dvbplayer.c)
>>> locks
>>> | the cDvbPlayer object most of the time when an editing mark is
>>> first jumped
>>> | to. The symptoms are cured by adding a call to sched_yield() before
>>> | LOCK_THREAD in cDvbPlayer::Action(void).
>
>
> Well, I do not have this sched_yield() in my code version, but maybe I
> do not see any effects of missig it as my development PC has an
> HyperThreading processor. When the unlock happens, the other waiting
> thread might immediately be able to enter the critical section.
>
After comparing rev.3 and rev.4 of this patch, I noticed that you removed all
the fixIFrame functions. Fixing the IFrames is no longer an issue?
Thanks for all your great patches..
Best Regards,
C.Y.M.
