non-perl lightweight Squeezebox Server?

[Steevee28]

Hi!
Is there a non-perl lightweight version of the Squeezebox Server? Or is such version planned?

I truly believe that this would make me - and many other people having small embedded systems - extremely happy!

I already tried running some elder Slimserver 6.x and a Squeeze Center 7.3.x on my router (WL-500gPv2) that currently serves as NAS (with UPnP streaming btw.), but pressing a button on the Squeezebox Remote meant waiting for 2 minutes (no joke!) before something happened. So this was useless.

So, if there is no such version, PLEASE think about reengineering this software in some programming language providing better performance.

Thank You!
Best regards

[snarlydwarf]

So, if there is no such version, PLEASE think about reengineering this software in some programming language providing better performance.

Why are you blaming perl for performance issues?

Perl is actually quite spiffy in speed.

[andyg]

Try the embedded branch: http://wiki.slimdevices.com/index.php/Nightly_Builds

[bpa]

I don't think the embedded SBS version will work well on a 240MHz 32Mbyte system.

I have run SS 6.3 on a Freecom 225MHZ 64Mbyte NAS and the response times was about 1 sec so I think the routing functionality of the WL500 is talking too much CPU /IO or perhaps memory for SS to function properly.

I think you would be better off buying a $99 plugcomputer such as a Sheevaplug.

[andyg]

32M? Yeah, forget it. There are alternate servers that use less memory, but no surprise, all your favorite features are missing.

[pippin]

Perl is actually quite spiffy in speed.

As compared to what? BASIC?
Perl is the sole reason we have to have the ridiculous WebUI removal in SBS embedded. I mean, every wristwatch runs a Web Server these days and SBT will not, that's a decision that will really, really, hurt some day, IMHO.
And it's for the sole reason that Perl sucks so much...

[snarlydwarf]

As compared to what? BASIC?

Compared to many other languages.

There are design issues in SBS that have been inherited over the years that perform horribly: many are how queries are constructed, for example, and the way the webui builds and executes such queries. There are some painfully slow queries in the webui: which is the result of the schema, mysql, and the query method.

Perl is the sole reason we have to have the ridiculous WebUI removal in SBS embedded. I mean, every wristwatch runs a Web Server these days and SBT will not, that's a decision that will really, really, hurt some day, IMHO.
And it's for the sole reason that Perl sucks so much...

I believe you are blaming the language for 5 or 10 year old design decisions.

It's like blaming a hammer for problems in a house.

SpamAssassin is in perl, and I execute it on a 9 year old server (single cpu!) on a hundred thousand or so pieces of mail a day.... It is quite speedy. I've run 'cleanfeed', an ancient usenet news despammer on an ancient SS20 with well over a million articles a day getting scanned...

The language is quiet fast. SBS's use of perl in the way it generates the webui is not. But the queries behind the page generation would be slow in any language.

[mherger]

Speed != memory usage

[Steevee28]

32M? Yeah, forget it. There are alternate servers that use less memory, but no surprise, all your favorite features are missing.

Are there? I would accept less features as trade-off for a working server.

I'm also application developer and our company develops image processing for embedded systems (an ARM processor, however). 32MB is not much RAM, that's true, but it is definitely sufficient for streaming MP3s to some other device, and also sufficient for running a web server.

So IMHO, I have to agree with others here that there have been made some unfortunate design decisions like Perl or MySQL that are to blame for the bad performance on small embedded systems.

[Steevee28]

I have run SS 6.3 on a Freecom 225MHZ 64Mbyte NAS and the response times was about 1 sec so I think the routing functionality of the WL500 is talking too much CPU /IO or perhaps memory for SS to function properly.

So the problem seems to be the RAM, not CPU speed. The CPU of the router idles about 95% when SBS is not running.
Hm...