Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 2 of 2
  1. #1
    Michael Dubno
    Guest

    Insane number of timers: 501 crash

    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..

  2. #2
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    Insane number of timers: 501 crash

    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..
    >

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •