Zitat von Martin Wache <[EMAIL PROTECTED]>:
> Stefan Lucke schrieb:
> > Zitat von Stefan Lucke <[EMAIL PROTECTED]>:
> >
> >> Zitat von Martin Wache <[EMAIL PROTECTED]>:
> >>
> >>> Stefan Lucke schrieb:
> >>>> On Samstag 30 September 2006 20:04, Marko Mäkelä wrote:
> >>>>> On Sat, Sep 30, 2006 at 05:32:06PM +0100, Laz wrote:
> >>>>>> I usually let mine turn itself on and off with nvram-wakeup! I see
> >>>>>> the problem when I leave it for a short while in the middle of
> >>>>>> something
> >>>>>> and get distracted!
> >>>>> Me too. Sometimes, I hit the Power button followed by some other button
> >>>>> to suspend the playback and to prevent the system from powering off.
> >>>>> Then, I'd hit the Power button to resume.
> >>>>>
> >>>>>> Hmmm...if you're right about this, how long should it take to
> >>>>>> overflow? The
> >>>>>> only counter I can see is a 64-bit integer which looks like it's
> >>>>>> counting in
> >>>>>> useconds which would take a few million years to overflow, by my
> >>>>>> reckoning!
> >>>>>> Maybe I'm looking in the wrong place and it's a 32-bit counter which
> >>>>>> would
> >>>>>> take 1 h 12 min to overflow. Not sure it was taking that long but it's
> >>>>>> hard
> >>>>>> to tell.
> >>>> Negative values should not harm,as we would return immedeatly.
> >>>>
> >>> I think the problem is in cSyncTimer::GetRelTime() which returns an
> >>> signed int. If GetRelTime() returns a negative number because of an
> >>> overflow we will actually add that value to delay instead of
> >>> substracting, when we do the ususal delay-=GetRelTime().
> >> The -= operator is the one which is causing troubles.
> >
> > That computed value is not only issue in that situation. I managed to
> > avoid hang by some other changes. With current code we are loosing a signal
> > to
> > the condition variable.
> > I did the following changes to sync_timer.c
> > 1. cSigTimer::Sleep() clear signal "got_signal=false;" only if would not
> > sleep.
> >
> > -- snip --
> > /* --- cSigTimer
> > --------------------------------------------------------------
> > */
> > int cSigTimer::Sleep(int timeoutUS, int lowLimitUS)
> > {
> > if ( timeoutUS < lowLimitUS ) {
> > got_signal=false;
> > return GetRelTime();
> > }
> >
> > -- snip --
> >
> > 2. cSyncTimer::Sleep(): clear signals "got_signal=false;" only in case of
> > emUsleepTimer and emRtcTimer.
> >
> > -- snip --
> > /*
> > ----------------------------------------------------------------------------
> > */
> > void cSyncTimer::Sleep(int *timeoutUS, int lowLimitUS)
> > {
> > switch(syncMode)
> > {
> > case emUsleepTimer: // usleep timer mode
> > while ((*timeoutUS - lowLimitUS) > 2200 && !got_signal)
> > {
> > usleep (2200);
> > *timeoutUS -= GetRelTime ();
> > }
> > break;
> > got_signal=false;
>
> This line is never executed.
Obvious. These lines have to be exchanged. Thats due to the fact, the
enviroment here
at my wife's father has a crippled internet access, and I cannot post cvs
diffs. The code I ran
had these lines swapped (sig timer mode).
The key for sigtimer is, that got_signal must not be cleared at entry of sleep
to avoid
loosing pending signals. For other timers it sould be done like sig timer:
clear that at
end of sleep action.
There may be still an issue with syncing after that long pause and so your
suggestion may still
be required.
As all (your's and mine) seems to fix the situation and all address real
issues, we should apply
all of them.
[ -- snip -- ]
> >
> > With these two modifications vdr did _not_ hang after the 40min sleep.
> >
> because got_signal is never set to false... And thus there is no
> sleeping at all.
> This will break the syncing completely. Maybe you don't notice it with
> DirectFB, because there is still the syncing to the Refreshrate.
>
> > One thing I did not test in case of real long Sync() is in video.c.
> > Sync() is protected by oldPictureMutex and would lock video thread from
> > event processing.
In between I did that test (reverted hang fix, changed oldPictureMutex lock
start) and result was as expected: video is hanging, but OSD interaction is ok.
> >
> Well, maybe we should move the whole syncing to cVideo::Action() and
> introduce a picture queue, then we could get rid of the oldPictureMutex
> at all... I will think about this..
>
> >> I guess we should
> >> introduce a private member "clampValue" , and return values of TimePassed()
> >> and GetRelTime() should be clamped to +/- clampValue if it is nonzero.
> >>
> GetRelTime() and TimePassed() is anyway a code duplication, that should
> be fixed too.
They only differ in setting the refence time marker.
> I would just limit the time which on can measure with
> GetRelTime() and TimePassed() to a reasonable time, lets say 15min or
> so. That is save to keep in 32bit. On longer waits GetRelTime() should
> just return the max value for 15min.
> I will send a patch this evening.
>
Stefan Lucke
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
