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.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdr-1.3.23-dvbplayer4.patch
Type: text/x-patch
Size: 1411 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20050507/1c3bb261/vdr-1.3.23-dvbplayer4.bin
