On Sat, Sep 30, 2006 at 05:36:45PM +0200, Martin Wache wrote:
> And here is a patch which hopefully fixes the problem (I'm trying
> currently it out, which obviously takes some time... but I wanted to
> shared it with you in case someone else wants to join the testing)
Your patch might fix the "long pause" problem but not the hang that
I am experiencing. My vdr-suspend patch simply stops the delivery
of MPEG packets to other than recorder threads. Would it be possible
to reset and stop the timers in cMpeg2Decoder::Clear() as well?
As far as I know, several vdr packagers apply the vdr-suspend patch,
but the feature is disabled in the default configuration. I am
afraid that several people could be affected by this. Maybe the hang
only occurs in conjunction with the vdr-subtitles plugin when there
are DVB subtitles being displayed at resume time.
On the other hand, I may need to rework the vdr-suspend patch anyway.
In its current form, it does not work on full-featured cards, nor
does it blank the screen. (It used to blank the screen on softdevice,
relying on its built-in blank timer.)
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.
I would have believed that one hang occurred after a 40-minute suspension.
Could it perhaps be a signed counter, counting 1<<31 microseconds before
overflow?
Marko
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
