damn, 0 used to work.  That's why I changed teh settings hash from a minimum of
0.001 to allow 0.  If this locks up (and it used to way back when as well) then
the setup hash can just be back to 0.001 again.  That should be safe.

Got patch?

Created attachment 71 [details]
the patch in question

this limits the scrollpause to something just above zero, and will set to that
limit if a user enters 0.  seems to work for me, but so does 0.

Well, 0 is a perfectly valid number from the user's perspective.  I forgot to include this important 
information in the original bug:

Illegal division by zero at /Users/sfrawley/Library/PreferencePanes/SlimServer.prefPane/Contents/
server/Slim/Display/Animation.pm line 624.

Does this help you reproduce?

do you mean scroll RATE?
the divide on line 624 is framedelay, which shoudl be tied to rate.

I tried a rate of 0 and I got the crash that you mention.  to allow the user to
enter 0, I'll make a patch that simply checks for 0.  if its 0, then we'll just
skip the whole animation routine.

Created attachment 72 [details]
proper patch for scrollrate

This will simply bypass animation of any kind if scrollrate or doublerate are
set to 0. It also removes checks for animationlevel since that isn't used any
more.  note: this patch is subsequent to bug428. if you like, I'll commit
tonight and change the string to clarify that 0 = no animation.

committed July 21, 2004

There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006.  I am setting them to targets of 6.2.1 to keep them from showing up in my queries.

Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.