On 01.11.2010 20:50, Teemu Suikki wrote:
>>> Hmm, I noticed that my OSD Flush time was set to 59 seconds in VDR
>>> settings.. If I drop that to some small value like 5 seconds, VDR
>>> doesn't hang anymore because the watchdog is not triggered for such a
>>> short time.
>> No idea about the cause, but I'd like to point out that the value range for
>> the dxr3 plugin's OSD flush rate is 0 to 255 _milli_seconds.
> Ah sorry my mistake. It's not OSD flush I was talking about, it's the
> vdr message display timeout or whatever.. :) For some reason I thought
> that was the "OSD flush" time.
> Anyway, there's two separate bugs:
> 1) If the message display time is over 30sec, the watchdog will
> timeout if there is another message in the queue waiting to be
> displayed.
> 2) VDR deadlocks when it tries to panic exit on that situation..
> This could be a bug in VDR and not dxr3 plugin, though.
> Now I have the message display time set at 5 secs and it hasn't frozen
> for several days now, so perhaps there's no reason to bother with this
> bug. :) Easy fix would be to limit the message display time to 15secs
> for example, so user can't set it too high by accident.

But this would also mean that there would have to be a lower limit
to the watchdog timer that is larger than this limit.

The original problem is apparently some deadlock in the area of
cSkins::ProcessQueuedMessages(). As you already found out it only
happens if the message timeout exceeds the watchdog timeout.
However, I would actually expect that to work, because AFAICS
there is no place where VDR actively waits for the message
timeout, so the main program loop should be still running if
a message is displayed.

I'm afraid I don't have the time to dig into this now. If the message
timeout is small compared to the watchdog timeout, all is fine.
If somebody can point out where the deadlock happens, I would
appreciate that.


vdr mailing list

Reply via email to