Software implementation of SliMP3

[Paul Warren]

Are there any software implementations of the SliMP3 protocol? I'm
aware of triplefat, but I'm looking for something that does the audio
rather than the UI.

I currently use mpg123 pointed at stream.mp3, but there are limitations
with this (slow response, mp123 getting upset and dieing).

I might have a go at implementing this myself, but wanted to check that
it hasn't already been done.

Paul

[Paul Warren]

On Mon, Dec 08, 2003 at 05:49:27PM +0000, Paul Warren wrote:
> Are there any software implementations of the SliMP3 protocol? I'm
> aware of triplefat, but I'm looking for something that does the audio
> rather than the UI.
>
> I currently use mpg123 pointed at stream.mp3, but there are limitations
> with this (slow response, mp123 getting upset and dieing).
>
> I might have a go at implementing this myself, but wanted to check that
> it hasn't already been done.

Can someone point me to the protocol docs? They don't appear to be
under cvs/docs, as the website suggests.

Paul

[Kevin Deane-Freeman]

Quoting Paul Warren <pdw (AT) ex-parrot (DOT) com>:

> On Mon, Dec 08, 2003 at 05:49:27PM +0000, Paul Warren wrote:
> > Are there any software implementations of the SliMP3 protocol? I'm
> > aware of triplefat, but I'm looking for something that does the audio
> > rather than the UI.
> >
> > I currently use mpg123 pointed at stream.mp3, but there are limitations
> > with this (slow response, mp123 getting upset and dieing).
> >
> > I might have a go at implementing this myself, but wanted to check that
> > it hasn't already been done.
>
> Can someone point me to the protocol docs? They don't appear to be
> under cvs/docs, as the website suggests.
>
look in your slimserver's help section, under technical information.

-kdf

[Roy M. Silvernail]

On Monday 08 December 2003 20:51, Kevin Deane-Freeman wrote:
> Quoting Paul Warren <pdw (AT) ex-parrot (DOT) com>:

> > Can someone point me to the protocol docs? They don't appear to be
> > under cvs/docs, as the website suggests.
>
> look in your slimserver's help section, under technical information.

I hate to have to point this out, but:

| Note: This document describes the previous version of the SLIMP3 protocol.
| This document will be updated to accurately reflect the current protocol. It
| also doesn't describe the Squeezebox control protocol. Sorry.

Looks like we have to wait a bit.

[Kevin Deane-Freeman]

Quoting "Roy M. Silvernail" <roy (AT) rant-central (DOT) com>:

> On Monday 08 December 2003 20:51, Kevin Deane-Freeman wrote:
> > Quoting Paul Warren <pdw (AT) ex-parrot (DOT) com>:
>
> > > Can someone point me to the protocol docs? They don't appear to be
> > > under cvs/docs, as the website suggests.
> >
> > look in your slimserver's help section, under technical information.
>
> I hate to have to point this out, but:
>
> | Note: This document describes the previous version of the SLIMP3 protocol.
> | This document will be updated to accurately reflect the current protocol.
> It
> | also doesn't describe the Squeezebox control protocol. Sorry.
>
> Looks like we have to wait a bit.

aye. docs are a hard thing to keep up.
if you are familiar with Perl, try having a gander at Networking/Protocol.pm
it can at least get you started as to what has changed since the help docs were
written.

sorry ;)

-kdf

[Paul Warren]

On Mon, Dec 08, 2003 at 07:34:57PM -0800, Kevin Deane-Freeman wrote:
> Quoting "Roy M. Silvernail" <roy (AT) rant-central (DOT) com>:
>
> > | Note: This document describes the previous version of the SLIMP3 protocol.
> > | This document will be updated to accurately reflect the current protocol.
> > It
> > | also doesn't describe the Squeezebox control protocol. Sorry.
> >
> > Looks like we have to wait a bit.
>
> aye. docs are a hard thing to keep up.
> if you are familiar with Perl, try having a gander at Networking/Protocol.pm
> it can at least get you started as to what has changed since the help docs were
> written.

Well, I guess that's the beauty of Open Source - it's documented in the
source if nowhere else. Perhaps someone could give me a few pointers...

- The old protocol was UDP. The new one uses TCP, correct?

- Which version of the server implemented this change?

- The squeezebox has its own protocol? What does that do?

thanks,

Paul

[dean]

The Squeezebox and SLIMP3 protocols are very different. To look at the
source, the SLIMP3 stuff is implemented in:

Slim::Networking::Stream
Slim::Networking::Protocol
Slim::Player::Slim

and the Squeezebox stuff is in:

Slim::Networking::SlimProto
Slim::Player::Squeezebox

Of course there's a lot of help from the other modules, but that's the
core.

-dean

On Dec 9, 2003, at 2:03 AM, Paul Warren wrote:

> On Mon, Dec 08, 2003 at 07:34:57PM -0800, Kevin Deane-Freeman wrote:
>> Quoting "Roy M. Silvernail" <roy (AT) rant-central (DOT) com>:
>>
>>> | Note: This document describes the previous version of the SLIMP3
>>> protocol.
>>> | This document will be updated to accurately reflect the current
>>> protocol.
>>> It
>>> | also doesn't describe the Squeezebox control protocol. Sorry.
>>>
>>> Looks like we have to wait a bit.
>>
>> aye. docs are a hard thing to keep up.
>> if you are familiar with Perl, try having a gander at
>> Networking/Protocol.pm
>> it can at least get you started as to what has changed since the help
>> docs were
>> written.
>
> Well, I guess that's the beauty of Open Source - it's documented in the
> source if nowhere else. Perhaps someone could give me a few
> pointers...
>
> - The old protocol was UDP. The new one uses TCP, correct?
>
> - Which version of the server implemented this change?
>
> - The squeezebox has its own protocol? What does that do?
>
> thanks,
>
> Paul
>

[Kevin Deane-Freeman]

Quoting Paul Warren <pdw (AT) ex-parrot (DOT) com>:

> On Mon, Dec 08, 2003 at 07:34:57PM -0800, Kevin Deane-Freeman wrote:
> > Quoting "Roy M. Silvernail" <roy (AT) rant-central (DOT) com>:
> >
> > > | Note: This document describes the previous version of the SLIMP3
> protocol.
> > > | This document will be updated to accurately reflect the current
> protocol.
> > > It
> > > | also doesn't describe the Squeezebox control protocol. Sorry.
> > >
> > > Looks like we have to wait a bit.
> >
> > aye. docs are a hard thing to keep up.
> > if you are familiar with Perl, try having a gander at
> Networking/Protocol.pm
> > it can at least get you started as to what has changed since the help docs
> were
> > written.
>
> Well, I guess that's the beauty of Open Source - it's documented in the
> source if nowhere else. Perhaps someone could give me a few pointers...
>
> - The old protocol was UDP. The new one uses TCP, correct?
Slimp3 uses UDP and still does
Squeezebox uses TCP (slimproto.pm)
>
> - Which version of the server implemented this change?
SlimServer 5.0 is the start of the TCP support. I'm not sure which specific
version of Slimp3 Server made the larger changes in the UDP protocol where the
current docs became obsolete.
>
> - The squeezebox has its own protocol? What does that do?
streams music to the squeezebox ;) Generally allows more useful bandwidth, less
overhead and some room to grow its uses in the future.

-kdf

[David Ranch]

Hey Dean,

Obviously the SqueezeBox is the new direction for SlimDevices but I'm curious
about future SW support for the legacy Slimp3 player. Will SlimDevices
continue to test against this HW platform? If so, any plans to discontinue
support in the future?

--David



>The Squeezebox and SLIMP3 protocols are very different. To look at the
>source, the SLIMP3 stuff is implemented in:
>
>Slim::Networking::Stream
>Slim::Networking::Protocol
>Slim::Player::Slim
>
>and the Squeezebox stuff is in:
>
>Slim::Networking::SlimProto
>Slim::Player::Squeezebox
>
>Of course there's a lot of help from the other modules, but that's the
>core.
>
>-dean
..----------------------------------------------------------------------------.
| David A. Ranch - Linux/Networking/PC hardware dranch (AT) trinnet (DOT) net |
!---- ----!
`----- For more detailed info, see http://www.ecst.csuchico.edu/~dranch -----'

[dean]

We intend to fully support SLIMP3.

-dean

On Dec 12, 2003, at 4:55 AM, David Ranch wrote:

>
> Hey Dean,
>
> Obviously the SqueezeBox is the new direction for SlimDevices but I'm
> curious about future SW support for the legacy Slimp3 player. Will
> SlimDevices continue to test against this HW platform? If so, any
> plans to discontinue support in the future?
>
> --David
>
>
>
> >The Squeezebox and SLIMP3 protocols are very different. To look at
> the
> >source, the SLIMP3 stuff is implemented in:
> >
> >Slim::Networking::Stream
> >Slim::Networking::Protocol
> >Slim::Player::Slim
> >
> >and the Squeezebox stuff is in:
> >
> >Slim::Networking::SlimProto
> >Slim::Player::Squeezebox
> >
> >Of course there's a lot of help from the other modules, but that's the
> >core.
> >
> >-dean
> .----------------------------------------------------------------------
> ------.
> | David A. Ranch - Linux/Networking/PC hardware
> dranch (AT) trinnet (DOT) net |
> !----
> ----!
> `----- For more detailed info, see
> http://www.ecst.csuchico.edu/~dranch -----'
>
>

[Paul Warren]

On Fri, Dec 12, 2003 at 08:21:47AM -0800, dean blackketter wrote:
> We intend to fully support SLIMP3.

Excellent. Do you intend to merge the two protocols at any point?

Paul

[dean]

Nope. SLIMP3 has pretty much hit the end of it's capabilities. We'll
need to support it as a legacy protocol.

-dean

On Dec 12, 2003, at 8:27 AM, Paul Warren wrote:

> On Fri, Dec 12, 2003 at 08:21:47AM -0800, dean blackketter wrote:
>> We intend to fully support SLIMP3.
>
> Excellent. Do you intend to merge the two protocols at any point?
>
> Paul
>

[Randy Gobbel]

Merging two such dissimilar protocols seems like it would be very
difficult. Which brings up--is the documentation for the two protocols
available somewhere? If so, I haven't found it.

From reading the sources, I've discovered that the SLIMP3 works by
sending the stream directly to the player via UDP (see 'unpause', in
Stream.pm), whereas the Squeezebox connects to the server via HTTP,
using a "stream.mp3" URL, similar to software players like Winamp.
Having gotten that far, I'm no longer surprised that there are glitches
when trying to synchronize a SLIMP3 and a Squeezebox--more like, how can
it work to synchronize these devices, when they work so differently?

Incidentally, it seems like this also implies that you should be able to
sync up Winamp with a Squeezebox (if the software allowed it), just by
adjusting the buffering settings by hand.

-Randy

Paul Warren wrote:

>On Fri, Dec 12, 2003 at 08:21:47AM -0800, dean blackketter wrote:
>
>
>>We intend to fully support SLIMP3.
>>
>>
>
>Excellent. Do you intend to merge the two protocols at any point?
>
>Paul
>

[dean]

On Dec 12, 2003, at 11:46 AM, Randy Gobbel wrote:
> From reading the sources, I've discovered that the SLIMP3 works by
> sending the stream directly to the player via UDP (see 'unpause', in
> Stream.pm), whereas the Squeezebox connects to the server via HTTP,
> using a "stream.mp3" URL, similar to software players like Winamp.
> Having gotten that far, I'm no longer surprised that there are
> glitches when trying to synchronize a SLIMP3 and a Squeezebox--more
> like, how can it work to synchronize these devices, when they work so
> differently?
Exactly the hell I'm in right now... Trying to clean it up...

> Incidentally, it seems like this also implies that you should be able
> to sync up Winamp with a Squeezebox (if the software allowed it), just
> by adjusting the buffering settings by hand.
In theory, assuming that the system latency on the remote side is fixed.

-dean

> Paul Warren wrote:
>
>> On Fri, Dec 12, 2003 at 08:21:47AM -0800, dean blackketter wrote:
>>
>>> We intend to fully support SLIMP3.
>>>
>>
>> Excellent. Do you intend to merge the two protocols at any point?
>> Paul
>>

[Phil Barrett]

The attached patch and new file add a festive feel to the display.

Suggestions as to how (and indeed when) to activate the effect are
welcomed. For the moment you need to manually turn on the client
preference in slimserver.pref

Two caveats:
1. the bottom line won't scroll while this is running
2. due to the limited number of custom chars, I don't recommend using
the elapsed-time bar at the same time

Ho ho ho!

Phil

[dean]

I love it!

KDF is working hard on screensavers right now. Hopefully he can use
this as another example...

-dean

On Dec 12, 2003, at 12:57 PM, Phil Barrett wrote:

> The attached patch and new file add a festive feel to the display.
>
> Suggestions as to how (and indeed when) to activate the effect are
> welcomed. For the moment you need to manually turn on the client
> preference in slimserver.pref
>
> Two caveats:
> 1. the bottom line won't scroll while this is running
> 2. due to the limited number of custom chars, I don't recommend using
> the elapsed-time bar at the same time
>
> Ho ho ho!
>
> Phil
> <snow.diff><Snow.pm>

[Randy Gobbel]

By the way, I discovered that by commenting out the "isPlayer" check
that keeps the server from trying to sync with software players, I can
get the server massively wrapped around itself. It winds up sending a
good stream to one of the two, very little (that I can hear) to the
other. This might not be relevant to anything, or it might be a good
stress test for the streaming code.

-Randy

dean blackketter wrote:

>
> On Dec 12, 2003, at 11:46 AM, Randy Gobbel wrote:
>
>> From reading the sources, I've discovered that the SLIMP3 works by
>> sending the stream directly to the player via UDP (see 'unpause', in
>> Stream.pm), whereas the Squeezebox connects to the server via HTTP,
>> using a "stream.mp3" URL, similar to software players like Winamp.
>> Having gotten that far, I'm no longer surprised that there are
>> glitches when trying to synchronize a SLIMP3 and a Squeezebox--more
>> like, how can it work to synchronize these devices, when they work so
>> differently?
>
> Exactly the hell I'm in right now... Trying to clean it up...
>
>> Incidentally, it seems like this also implies that you should be able
>> to sync up Winamp with a Squeezebox (if the software allowed it),
>> just by adjusting the buffering settings by hand.
>
> In theory, assuming that the system latency on the remote side is fixed.
>
> -dean
>
>> Paul Warren wrote:
>>
>>> On Fri, Dec 12, 2003 at 08:21:47AM -0800, dean blackketter wrote:
>>>
>>>> We intend to fully support SLIMP3.
>>>>
>>>
>>> Excellent. Do you intend to merge the two protocols at any point?
>>> Paul
>>>

[kdf]

Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> I love it!
>
> KDF is working hard on screensavers right now. Hopefully he can use
> this as another example...

no pressure ;)

I'll certainly be using it for testing :)

-kdf

[kdf]

phil, any chance you could work it into the plugin API?

I know it will make you have to navigate to use it, but the screensaver will
operate on plugins and it will save me a lot of time converting it to a plugin
form myself. I promise, once the screensavers work, you wont have to click
after setting it as your default screensaver :)

-kdf



Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> The attached patch and new file add a festive feel to the display.
>
> Suggestions as to how (and indeed when) to activate the effect are
> welcomed. For the moment you need to manually turn on the client
> preference in slimserver.pref
>
> Two caveats:
> 1. the bottom line won't scroll while this is running
> 2. due to the limited number of custom chars, I don't recommend using
> the elapsed-time bar at the same time
>
> Ho ho ho!
>
> Phil
>

[Roy M. Silvernail]

On Friday 12 December 2003 15:57, Phil Barrett wrote:
> The attached patch and new file add a festive feel to the display.

That is *cute*!

[kdf]

Awesome toy phil!

I've modified it to fit with the brand spanking new screensaver API. Here is
the plugin version, which is designed to work with the latest CVS. It should be
compatible with the nightly version either today or tomorrow.

One caution, the snow plugin is VERY cpu intensive. It worked itself up to 99%
on my Althlon 2k

Let the games begin....

-kdf


Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> The attached patch and new file add a festive feel to the display.
>
> Suggestions as to how (and indeed when) to activate the effect are
> welcomed. For the moment you need to manually turn on the client
> preference in slimserver.pref
>
> Two caveats:
> 1. the bottom line won't scroll while this is running
> 2. due to the limited number of custom chars, I don't recommend using
> the elapsed-time bar at the same time
>
> Ho ho ho!
>
> Phil
>

[Phil Barrett]

On 13 Dec 2003, at 08:42, kdf wrote:
> Awesome toy phil!

Glad you like it!

> I've modified it to fit with the brand spanking new screensaver API.
> Here is
> the plugin version, which is designed to work with the latest CVS. It
> should be
> compatible with the nightly version either today or tomorrow.

Excellent - thanks for doing that.

> One caution, the snow plugin is VERY cpu intensive. It worked itself
> up to 99%
> on my Althlon 2k

I suspect this is at least partly due to my misunderstanding the Timer
code. I assumed that calling
Slim::Utils::Timers::setTimer($client, Time::HiRes::time() + 0.5,
\&tick);
just scheduled the timer for half a second in the future.

But leaving Snow running overnight, I got this error:
Insane number of timers: 501

Manually cancelling the timer improves CPU usage dramatically.

Revised plugin attached.

Phil

[Phil Barrett]

On 13 Dec 2003, at 09:34, Phil Barrett wrote:
> On 13 Dec 2003, at 08:42, kdf wrote:
>> I've modified it to fit with the brand spanking new screensaver API.
>> Here is
>> the plugin version, which is designed to work with the latest CVS.
>> It should be
>> compatible with the nightly version either today or tomorrow.

A couple of requests for the API:

1. If the plugin could request a (minimum) update interval, I wouldn't
need to use a timer at all
2. The screensaver doesn't run in 'off' mode, which means no snow on
the clock :-(

Phil

[kdf]

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:


> 1. If the plugin could request a (minimum) update interval, I wouldn't
> need to use a timer at all
I'm hesitant to add timers that run all the time. However, it does make sense,
being as this is a screensaver. I'll have to defer to Dean's call on this one.

> 2. The screensaver doesn't run in 'off' mode, which means no snow on
> the clock :-(
That's a legacy thing. 'off' was a mode on its own. Also, being a plugin, its
not so easy to call up whatever the current lines are. I just used current song
lines, but you could change the plugin to use dateTime() for the $linefunc.
line 144:
my $linefunc = \&Slim::Buttons::Common::dateTime($client);

you can probably write some configuration in the plugin section to let users
choose to have snow over current song, or snow over time. Or, make it automatic
by checking if the player is currently playing to show currentSongLines and if
not, show dateTime.

there is lots of flexibiliity there. I can certainly remove the condition int
eh screensaver code to let it still trigger even when off, but the plugin as it
is now will still switch to the current song lines.

cheers,
kdf

[kdf]

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> On 13 Dec 2003, at 09:34, Phil Barrett wrote:
> > On 13 Dec 2003, at 08:42, kdf wrote:
> >> I've modified it to fit with the brand spanking new screensaver API.
> >> Here is
> >> the plugin version, which is designed to work with the latest CVS.
> >> It should be
> >> compatible with the nightly version either today or tomorrow.
>
> A couple of requests for the API:
>
> 1. If the plugin could request a (minimum) update interval, I wouldn't
> need to use a timer at all
some more info on this. part o fthe reason the cpu blew up on the first version
is that the lines do have a built in update rate from the screensaver. This is
set at 1s. This 'could' be adjusted with a client parameter without too much
trouble. The timer can be removed now, if you dont mind a 1s update.

> 2. The screensaver doesn't run in 'off' mode, which means no snow on
> the clock :-(
my mistake on the last post. the line should be 146, replacing the parameter
for renderOverlay like so:
renderOverlay(&Slim::Buttons::Common::dateTime($client));

this way you do get a clock.

-kdf

[dean]

On Dec 13, 2003, at 2:07 AM, kdf wrote:

> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
>
>
>> 1. If the plugin could request a (minimum) update interval, I wouldn't
>> need to use a timer at all
> I'm hesitant to add timers that run all the time. However, it does
> make sense,
> being as this is a screensaver. I'll have to defer to Dean's call on
> this one.
It's a bug in the screensaver. If it gets called once a second and
every time it gets called it spawns another one, you'll quickly be
overwhelmed with timers.

Screensavers should have a lines() function, and should feel free to
draw themselves faster if wanted through timers, but growing
exponentially is bad.

[Phil Barrett]

Attached is the latest Snow plugin, featuring numerous improvements,
including a number of settings menus.

Enjoy.

Phil

NB It appears that if the screen is in double-size mode and a long song
name is scrolling, the screen dims, but the screensaver isn't activated
and the text continues to scroll.

[kdf]

go Phil!!

I'm glad you started to play with the features. I was going to do some myself
to as a show of screensaver options, but its great to have someone else taking
it for a spin :)

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> Attached is the latest Snow plugin, featuring numerous improvements,
> including a number of settings menus.
>
> Enjoy.
>
> Phil
>
> NB It appears that if the screen is in double-size mode and a long song
> name is scrolling, the screen dims, but the screensaver isn't activated
> and the text continues to scroll.
>

[kdf]

one pointer...default values will prevent a great number of uninitialized value
errors if the screensaver starts before the settings are chosen ;)

-kdf

[dean]

Kevin,

Will you merge and test the fixes?

-dean

On Dec 13, 2003, at 3:37 PM, kdf wrote:

> one pointer...default values will prevent a great number of
> uninitialized value
> errors if the screensaver starts before the settings are chosen ;)
>
> -kdf
>
>
>

[kdf]

Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> Kevin,
>
> Will you merge and test the fixes?
>
> -dean
these are errors in the snow.pm plugin. the settings that phil added seem not
to pick up defaults. However, I do see that there is code to attempt to do so.
not sure why it didn't work for me. No merge necessary unless you want Snow.pm
added to the cvs ;)


> On Dec 13, 2003, at 3:37 PM, kdf wrote:
>
> > one pointer...default values will prevent a great number of
> > uninitialized value
> > errors if the screensaver starts before the settings are chosen ;)
> >
> > -kdf
> >

[dean]

I'd like an assortment of screensavers to show off your new framework.
Snow seems timely.

-dean

On Dec 13, 2003, at 5:09 PM, kdf wrote:

> Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:
>
>> Kevin,
>>
>> Will you merge and test the fixes?
>>
>> -dean
> these are errors in the snow.pm plugin. the settings that phil added
> seem not
> to pick up defaults. However, I do see that there is code to attempt
> to do so.
> not sure why it didn't work for me. No merge necessary unless you
> want Snow.pm
> added to the cvs ;)
>
>
>> On Dec 13, 2003, at 3:37 PM, kdf wrote:
>>
>>> one pointer...default values will prevent a great number of
>>> uninitialized value
>>> errors if the screensaver starts before the settings are chosen ;)
>>>
>>> -kdf
>>>
>

[kdf]

Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> I'd like an assortment of screensavers to show off your new framework.
> Snow seems timely.
>
> -dean

ok, patched to remove the error messages. Phil, all ok with you if this plugin
goes into the cvs?

-kdf

[Phil Barrett]

On 14 Dec 2003, at 06:11, kdf wrote:
> Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:
>> I'd like an assortment of screensavers to show off your new framework.
>> Snow seems timely.
>>
>> -dean
>
> ok, patched to remove the error messages. Phil, all ok with you if
> this plugin
> goes into the cvs?

Absolutely. Fame at last!

Phil

[kdf]

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> On 14 Dec 2003, at 06:11, kdf wrote:
> > Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:
> >> I'd like an assortment of screensavers to show off your new framework.
> >> Snow seems timely.
> >>
> >> -dean
> >
> > ok, patched to remove the error messages. Phil, all ok with you if
> > this plugin
> > goes into the cvs?
>
> Absolutely. Fame at last!

well, committed at least ;)
-kdf

[Dan Sully]

* Felix Mueller <fcm4711 (AT) yahoo (DOT) com> shaped the electrons to say...

> Hi Phil, Kevin and Dean
>
> I love that Snow Screensaver!
>
> Please find attached a patch for Snow.pm to allow
> different settings (Snow quantity, Snow style) for
> different players.

Commited. Thanks.

-D
--
Down, not across.