PDA

View Full Version : Insane number of timers: 501 crash



Michael Dubno
2004-07-06, 19:54
I'm actually not directly creating or killing them. All I'm doing is using
the http interface with -

http://slimserver:9000/status.txt?player=<something>&p0=display&p1=stuff&p2=
morestuff&p3=86400.0

This should display the data for up to a day in this case and then clear. My
software updates the data roughly every 5 seconds so a day for the timeout
is perhaps a bit long, but it used to work.

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Dan Sully
Sent: Tuesday, July 06, 2004 10:42 PM
To: Slim Devices Discussion
Subject: [slim] Insane number of timers: 501 crash

* Dan Sully <daniel (AT) electricrain (DOT) com> shaped the electrons to say...

>* Michael Dubno <michael (AT) dubno (DOT) com> shaped the electrons to say...
>
>>It seems that 5.2.1 introduced a new bug - "Insane number of timers: 501"
>>which did not occur in earlier version. My guess is that this is being
>>triggered by my use of the slim devices to send frequent display updates
of
>>weather. Each update has a timeout set to prevent the display of stale
>>data
>>over time. Perhaps the perl code for resetting or halting the timer got
>>modified in the last few weeks.
>
>Michael - perl can only have one active alarm() statement at any one time.
>Each new call to alarm() will reset the timer. Might that be causing your
problem?

Or rather (after looking at the code) - are you killing your timers after
creating them?

See Slim/Utils/Timers.pm

-D
--
It does not do to leave a live Dragon out of your calculations..

dean
2004-07-07, 07:29
Michael,

If you are sending this command every 5 seconds and telling it to
display for 86400 seconds, then it's not surprising that all these
overlapping display commands are causing the server to get confused.
(There's probably a bug in there where new display command should kill
the old one, but...)

What happens if you reduce the timeout to 10 seconds instead of a day?


On Jul 6, 2004, at 10:54 PM, Michael Dubno wrote:

> I'm actually not directly creating or killing them. All I'm doing is
> using
> the http interface with -
>
> http://slimserver:9000/status.txt?
> player=<something>&p0=display&p1=stuff&p2=
> morestuff&p3=86400.0
>
> This should display the data for up to a day in this case and then
> clear. My
> software updates the data roughly every 5 seconds so a day for the
> timeout
> is perhaps a bit long, but it used to work.
>
> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Dan Sully
> Sent: Tuesday, July 06, 2004 10:42 PM
> To: Slim Devices Discussion
> Subject: [slim] Insane number of timers: 501 crash
>
> * Dan Sully <daniel (AT) electricrain (DOT) com> shaped the electrons to say...
>
>> * Michael Dubno <michael (AT) dubno (DOT) com> shaped the electrons to say...
>>
>>> It seems that 5.2.1 introduced a new bug - "Insane number of timers:
>>> 501"
>>> which did not occur in earlier version. My guess is that this is
>>> being
>>> triggered by my use of the slim devices to send frequent display
>>> updates
> of
>>> weather. Each update has a timeout set to prevent the display of
>>> stale
>>> data
>>> over time. Perhaps the perl code for resetting or halting the timer
>>> got
>>> modified in the last few weeks.
>>
>> Michael - perl can only have one active alarm() statement at any one
>> time.
>> Each new call to alarm() will reset the timer. Might that be causing
>> your
> problem?
>
> Or rather (after looking at the code) - are you killing your timers
> after
> creating them?
>
> See Slim/Utils/Timers.pm
>
> -D
> --
> It does not do to leave a live Dragon out of your calculations..
>