PDA

View Full Version : Slimserver 6.5 MySQL Requirement - Bad!



mwatkins
2006-10-07, 08:40
I'm a long time slimserver user with an original squeezebox. Today I started to upgrade from 6.3.x to 6.5.x, only to note in the Makefile (FreeBSD ports) that MySQL is now a requirement.

Some mistake, I thought, it must be! But apparently not... although if someone can assure me that 6.5 and above will NOT require MySQL, that would be a big win.

Assuming that the developers indeed have made a dreadful mistake and made MySQL a requirement, I'd like to know... WHY?

The data model and processing requirements for a tool like Slimserver do not outgrow the abilities of so-called 'embeddable' databases such as sqlite. Convince me otherwise, if you can.

In my professional capacity I have shunned MySQL for years, but I'd be willing to rant on about this requirement even if the developers had standardized on a database engine which I prefer (Postgres, even Oracle or SQL Server). Including yet another big chunk of software raises other issues of security, compatibility and upgrades; yet another process on the box; another thing to manage and potentially backup.

So my question is... why?

edit: perhaps a more appropriate question is, why did the slimserver developers decide to pick a single client-server database rather than use middleware to standardize SQL calls in the application, thus permitting any backend. I can see standardizing on two common platforms - sqlite and begrudgingly mysql, but this approach would allow experienced users and administrators the option of using the backends they already have, are familiar with, and support - if they need it.

For folks that have a few thousand or so titles and don't need the complication of a c/s rdb, sqlite performs more than adequately.

Hoping for a decent explanation as to "why" MySql and only MySql was chosen, rather than a multi-db strategy (which is dirt simple these days).

FYI I won't be upgrading as long as this requirement remains in place, nor will be I purchasing other slimdevices produces that rely on slimserver 6.5 and above, with its attendant, new, wrongly adopted, requirement. I'm sure I'm not the only person that looks at software requirements and keeps on walking.

stinkingpig
2006-10-07, 17:56
On 10/7/06, mwatkins <mwatkins.2fbe4z1160235901 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> I'm a long time slimserver user with an original squeezebox. Today I
> started to upgrade from 6.3.x to 6.5.x, only to note in the Makefile
> (FreeBSD ports) that MySQL is now a requirement.
>
> Some mistake, I thought, it must be! But apparently not... although if
> someone can assure me that 6.5 and above will NOT require MySQL, that
> would be a big win.
>
> Assuming that the developers indeed have made a dreadful mistake and
> made MySQL a requirement, I'd like to know... WHY?
>
> The data model and processing requirements for a tool like Slimserver
> do not outgrow the abilities of so-called 'embeddable' databases such
> as sqlite. Convince me otherwise, if you can.


Best read the archives of the developer list. The thing that really did in
SQLite IMHO was its poor performance and high memory consumption, but IIRC
there were some problems with growing into more advanced SQL as well.


In my professional capacity I have shunned MySQL for years, but I'd be
> willing to rant on about this requirement even if the developers had
> standardized on a database engine which I prefer (Postgres, even Oracle
> or SQL Server). Including yet another big chunk of software raises other
> issues of security, compatibility and upgrades; yet another process on
> the box; another thing to manage and potentially backup.
>
> So my question is... why?
>
>
In my professional capacity I frequently deal with people who are married to
one technology choice or another. Since our product is closed source, I have
to tell them that they need to chose their marriage or our product, because
they can't have both. In this case, SlimServer is open source, so you're
perfectly welcome to fire up vi or emacs and DBI into something else. I'm
sure that the results would be welcomed on the wiki or as a patch. Of
course, this represents a high opportunity cost, but if you really care, the
option is there.

I don't really care. I've worked as an administrator and lightweight
devel/QA with MySQL, SQL Server, PostgreSQL, and Oracle... they all have
their issues, and they all have their positives. Unfortunately the SQL
standard is almost completely non-standard, so supporting more than one in a
given application means a lot of "if I'm on this database, use X, but this
other one needs Y, and the third one needs Z." That means poor performance.
At the end of the day, the database support decision is kind of like the
implementation language decision; you either grin and bear it, or you give
up, because supporting more than one is not feasible. That's just my opinion
though :)
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

mwatkins
2006-10-07, 22:01
I can't believe that the queries used by slimserver couldn't be abstracted sufficiently to avoid issues with various flavours of SQL. Its not like the queries needed to support a music catalogue are rocket science.

While its true that there are a great many differences between the various implementations of SQL, for a tool with needs as simple as slimserver's, using a middleware layer to hide those differences would have been an appropriate, even advantageous, decision.

Sure, taking the middleware db-abstraction approach would have resulted in more databases being used, with a corresponding impact on support queries from the multitudes. I understand that, but I don't agree with the decision.

A better decision would have been to use db-abstraction in the core, but announce support only for a single database, MySql if that is your choice. Solve the supportability issue by decree, rather than limiting the scope of the software's appeal. At least then you aren't walling the software off from others who might be interested in different sorts of mashups which might prove interesting to the community.

This isn't about being married to one technology, or me or others being biggoted against another. Given that there are a plethora of db-abstraction layers out there, and slimserver's db requirements are practically infantile, the decision smacks of poor product management choices.

PS: Good point about the implementation language. Always felt Perl was a poor choice for slimserver, but I grinned and bore that. But the difference is significant: perl I already must support on a wide fleet of machines at work and at home; MySql I do not have to support nor care to add it to the mix. Chances are that I will explore other options rather than invest in a new upgraded box for home, or one for the office I'd planned to add. What was once a no brainer decision for me now is less so.

I doubt my apparent reluctance to upgrade due to MySql dependency is going to be commonly shared, but certainly there will be some who feel as I do. Enough to matter, from a sales perspective? Perhaps not.

socialxray
2006-10-07, 22:35
Um...this is a consumer product. Not an enterprise product. It is transparent to the end user and that is all that counts. Sure, it is another process that is running on the box but it is still smaller than Slimserver's footprint. Plus it is a lot cheaper than an Oracle license.

Got to roll with the punches my man, or sit the game out.

BTW, I support multi-db strategies at my job and it ain't so dirt simple.

Jacob Potter
2006-10-07, 22:53
On 10/8/06, mwatkins
<mwatkins.2fcf6b1160283901 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> A better decision would have been to use db-abstraction in the core,
> but announce support only for a single database, MySql if that is your
> choice. Solve the supportability issue by decree, rather than limiting
> the scope of the software's appeal. At least then you aren't walling
> the software off from others who might be interested in different sorts
> of mashups which might prove interesting to the community.

SlimServer does exactly that, using DBIx::Class for all the database
O/RM stuff. The schema itself (in the SQL/ directory) would need to be
rewritten, but not too much more, I think.

You could perhaps have taken a peek at the code before ranting. :)

- Jacob

mwatkins
2006-10-07, 22:55
Slimserver didn't get any slimmer by adding MySql, my man.

I don't claim slimserver/squeezebox... to be enterprise products, but a certain, reasonably high, percentage of its users happen to be technical folks. Maybe the product line has enough mainstream appeal now that it doesn't matter, but generally speaking ticking off your technical base and early adopters isn't a great idea.

mwatkins
2006-10-07, 23:04
SlimServer does exactly that, using DBIx::Class for all the database O/RM stuff. The schema itself (in the SQL/ directory) would need to be rewritten, but not too much more, I think. You could perhaps have taken a peek at the code before ranting. :) - Jacob

That's a plus, although my original post was less of a rant, more of a question... turned slightly more ranty as time went on.

I had done a preliminary search through docs and forums to see if this issue had come up before and seeing nothing, posted the question; perhaps a FAQ entry "you can roll your own if you like" would be appropriate.

In an ideal world. the product would continue to support sqlite, *and* now MySql, with an install time option to choose one or the other. My two cents. Am not really interested in carrying this on further. In my day job I have to argue with, plead to, and convince product managers all the time who make brain dead decisions, from time to time... this is starting to resemble work a little too much.

Cheers.

Andrew L. Weekes
2006-10-08, 00:33
For folks that have a few thousand or so titles and don't need the complication of a c/s rdb, sqlite performs more than adequately.

I beg to differ.

On my Slimserver box, which is a lowly PIII 600, the performance improvement from migrating the database to MySQL was DRAMATIC.

Despite the extra processes, memory etc, it was a very obvious improvement in speed of response. That was under SS 6.3, so the only variable was the database itself, the SS code was unchanged.

I think we can all easily get bogged down by dogma, but what matters is results. The other arguments are irrelevant to most users, they don't care what database is used, they only care about whether it works or not, something it plainly does ;)

You haven't explained your dislike of MySQL, but from an end user's perspective it works very well, I use it in Slimserver and MythTV and it works perfectly in both app's, which is all that most users will be interested in.

Any other discussion for those users is nebulous and irrelevant.

Andy.

roamingstudio
2006-10-08, 02:06
If you read through the 3rd Party stuff there are quite a few threads showing that some of the NAS (network attached storage) devices are taking a huge hit in performance with 6.5.x This could well be due to the need for MySQL (or not - ive not had time to read the SS source code).

However an option to keep the old database format would possibly be good for these groups of people - if it works; dont fix it. If you need improved performance then the path is probably to have a custom mini-itx / PC based system; in which case MySQL is not a problem.

Just my 0.02$

erland
2006-10-08, 02:27
I really can't see the big problem here. We had a bundled database in 6.3(SQLite) in 6.5 we also have a bundled database(MySQL).

If you are a non technical person, you don't se any difference. There is no extra installation, there is no exta configuration.

If you are a technical person who didn't administate/manage the SQLite datbase with third party tools you won't se any difference. There is no extra configuration or management with the bundled MySQL compared to the earlier bundled SQLite database. The MySQL database bundled is by default configured with no network support, so the security risk shouldn't be a problem either.

If you are a technical person who cares about the database and wan't to administrate/manage it with third party tools, you will see the difference. Earlier you had to use user unfriendly tools towards a text file which could easily be corrupted, now with MySQL there is a lot of third party tools available which you can use to manage/administrate your database.

Slim Devices could of course have choosen to say that they support ANY database, but that would probably have been a huge hit on the support team which would result in that we would get less support for real problems. It would probably also have resulted in less time for the developers to implement real slimserver functions because they had to spend time to make sure to test the existing code toward all available database products.

The only bad thing I personally can see with MySQL is if it make slimserver not to work on low memory/slow CPU devices such as NAS boxes.

roamingstudio
2006-10-08, 02:49
The only bad thing I personally can see with MySQL is if it make slimserver not to work on low memory/slow CPU devices such as NAS boxes.
I think the NAS + SB3 / Transporter route is one a lot of people are going to favour in the future; and is not worth 'forgetting' about.

tommypeters
2006-10-08, 03:03
Seems to work on Synology for Flipflip and Mr Hyde, but on the other hand the DS-106 comes with MySQL pre-installed.

pfarrell
2006-10-08, 08:47
mwatkins wrote:
> Slimserver didn't get any slimmer by adding MySql, my man.

The devices are slim. The server serves them. It is not a tiny server,
it is a server for slim devices.

You are looking at it from the wrong viewpoint. The devices are simple,
slim and dumb. All the brains are in the server. The server is not slim,
it is feature rich. There is lots of demand for it to get more rich and
powerful, far more than folks wanting the server to be slimer.

It is all open source, if you don't like it, change it and submit patches.

Your subject line in inflamatory and unjustified. MySql is bundled, and
installed invisibly for 99% of the users. For technical folks who want
to use another Sql engine, you can do it.

As a technical person, you have to admit that there is no such thing as
a true sql standard implementation. Every implementation has tradeoffs.
While you can write to a pure SQL spec, all of the vendors improve the
language to make development easier. Once you start to use it, you
become tied into that dialect.

You can have preferences that differ from those chosen by the
developers. You can become a developer. Patches always welcome.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

mherger
2006-10-08, 12:15
> Assuming that the developers indeed have made a dreadful mistake and
> made MySQL a requirement, I'd like to know... WHY?

One reason that hasn't been mentioned is the inability (or buggyness in
this area?) of SQLite to serve more than one process. The scanner is now
run in a separate process.

> The data model and processing requirements for a tool like Slimserver
> do not outgrow the abilities of so-called 'embeddable' databases such
> as sqlite. Convince me otherwise, if you can.

May be the data model isn't complex, but the user in this application is
more demanding than your accountant: ours are used to waiting a second or
two for a new screen. Most of the users here don't want to wait so long
when browsing their music collection on the display. That said I'll add
that I've already been using MySQL with earlier SlimServers as it was
about 30% faster in tests using the CLI. Probably not representative, but
good enough a reason for me to swap.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

MrSinatra
2006-10-09, 19:23
Um...this is a consumer product. Not an enterprise product. It is transparent to the end user and that is all that counts. Sure, it is another process that is running on the box but it is still smaller than Slimserver's footprint. Plus it is a lot cheaper than an Oracle license.

Got to roll with the punches my man, or sit the game out.

BTW, I support multi-db strategies at my job and it ain't so dirt simple.

i can't say if a choice of db would be worthy or not, but i can say that i think SS is starting to become a resource hog.

3 processes in all that i am aware of. over time, mem usage grows as if there is a leak.

the mysql takes 16megs, the slim.exe takes an incredible 60 or so at start up, and then works its way up to over 75!!! this is the single biggest process on my system, with only the svchost close. the next closest app is outlook at 25 or so.

and then this i really don't get, the tray icon is 7.5meg! why??? to power its dumb lil lights? i like the way plextor runs its tray icon, subdued when plextools is exited, but still there ready to start up. still piggy at 2megs, but not as bad.

rudholm
2006-10-10, 10:56
I can't believe that the queries used by slimserver couldn't be abstracted sufficiently to avoid issues with various flavours of SQL. Its not like the queries needed to support a music catalogue are rocket science.

While its true that there are a great many differences between the various implementations of SQL, for a tool with needs as simple as slimserver's, using a middleware layer to hide those differences would have been an appropriate, even advantageous, decision.

Sure, taking the middleware db-abstraction approach would have resulted in more databases being used, with a corresponding impact on support queries from the multitudes. I understand that, but I don't agree with the decision.

A better decision would have been to use db-abstraction in the core, but announce support only for a single database, MySql if that is your choice. Solve the supportability issue by decree, rather than limiting the scope of the software's appeal. At least then you aren't walling the software off from others who might be interested in different sorts of mashups which might prove interesting to the community.

This isn't about being married to one technology, or me or others being biggoted against another. Given that there are a plethora of db-abstraction layers out there, and slimserver's db requirements are practically infantile, the decision smacks of poor product management choices.

PS: Good point about the implementation language. Always felt Perl was a poor choice for slimserver, but I grinned and bore that. But the difference is significant: perl I already must support on a wide fleet of machines at work and at home; MySql I do not have to support nor care to add it to the mix. Chances are that I will explore other options rather than invest in a new upgraded box for home, or one for the office I'd planned to add. What was once a no brainer decision for me now is less so.

I doubt my apparent reluctance to upgrade due to MySql dependency is going to be commonly shared, but certainly there will be some who feel as I do. Enough to matter, from a sales perspective? Perhaps not.

I think the fact that scan times improved with MySQL might not mean that MySQL was needed. It could also be evidence that there was something wrong with SS. I too have my doubts that PERL is the right choice for SS.

I really don't see why a full-blown transactional db back-end should be needed, even with tens of thousands of tracks.

I agree, buying more SBs would be a no-brainer if not for SS. SS is clearly the weak link in the whole SB proposition --the UI, the db, the performance...perhaps it's time for a complete re-do guys...

I know you guys love hardware (and, kudos, it really shows in the product) and the current SS is already developed, but if it were my money, I'd be taking a long hard look at slimserver.

JJZolx
2006-10-10, 12:59
Given all of the above, I have to imagine the possibility of moving to Apache for the underlying web server would certainly generate some interesting discussion...

http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap


Re-architect event/threading/forking model. Investigate using mod_perl / Apache to handle all the web based interaction, and have custom mod_perl protocol handlers for non-HTTP interaction (ie: SlimProto)

I already run Apache on my SlimServer machine, as well as MySQL, so the move would be welcome.

What becomes increasingly evident is that running SlimServer on anything other than a dedicated server is becoming less and less feasible as the software evolves and customers' expectations for robustness and responsiveness increases.

mherger
2006-10-10, 14:33
> What becomes increasingly evident is that running SlimServer on
> anything other than a dedicated server is becoming less and less
> feasible as the software evolves and customers' expectations for
> robustness and responsiveness increases.

I don't know why I should need a dedicated machine, really. I've no
problem running slimserver 6.5 with samba, apache, another MySQL instance,
mail... on the same two year old Via C3/1GHz with 512MB ram. That machine
does sometimes crash for unknown reasons. But it's been up for three
months now, surviving quite a few slimserver installations.

I'd bet most of the issues asking for a dedicated machine are due to some
other influence.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

pfarrell
2006-10-10, 14:45
Michael Herger wrote:
>> What becomes increasingly evident is that running SlimServer on
>> anything other than a dedicated server is becoming less and less
>> feasible as the software evolves and customers' expectations for
>> robustness and responsiveness increases.
>
> I don't know why I should need a dedicated machine, really. I've no
> problem running slimserver 6.5 with samba, apache, another MySQL
> instance, mail... on the same two year old Via C3/1GHz with 512MB ram.
> That machine does sometimes crash for unknown reasons. But it's been up
> for three months now, surviving quite a few slimserver installations.
>
> I'd bet most of the issues asking for a dedicated machine are due to
> some other influence.

Warning: "dedicated machine" is a loaded phrase.
There are two reasons that cause vendors to use this phrase:
1) to ensure that there is enough capacity to have "good" response.
2) to ensure that no other product's requirements don't conflict with
some obscure requirement of this product.

Both of these drive at the heart of the word "support" as in "Oracle
only supports X" or "To use XYZ accounting package, you need Y for support"

In simple english, it is a lot easier for Tech Support (for any vendor)
to support a dedicated machine. And for a lot of non-techical users, it
is easier for the customer as well.

The latest Mandriva distro, 2007, seems to have aimed at the naive
consumer so much that they have broken some "standard" development
tools. Does this mean that you can't use Mandriva 2007 and SlimServer?
no, just that it isn't as easy as it was with Mandriva 10.1, which was
easier than Mandriva 2006.

I had a friend get Windows XP working on a 233mHz machine with 96MB. It
was dog slow, but it ran. For me, anything under 512MB is unacceptable
for XP, and more CPU is always better. But what I want, and what is
possible are separate things.

Sometimes it is easier to "manage" and "support" simplier
configurations. That doesn't mean you can't do it if you are adventurous.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

JJZolx
2006-10-10, 14:56
I don't know why I should need a dedicated machine, really. I've no
problem running slimserver 6.5 with samba, apache, another MySQL instance,
mail... on the same two year old Via C3/1GHz with 512MB ram. That machine
does sometimes crash for unknown reasons. But it's been up for three
months now, surviving quite a few slimserver installations.
I meant a dedicated server, not necessarily a machine dedicated only to running SlimServer. Something not used as a desktop for playing Warcraft, watching porn, etc.

stinkingpig
2006-10-10, 15:01
On 10/10/06, Michael Herger <slim (AT) herger (DOT) net> wrote:
>
> > What becomes increasingly evident is that running SlimServer on
> > anything other than a dedicated server is becoming less and less
> > feasible as the software evolves and customers' expectations for
> > robustness and responsiveness increases.
>
> I don't know why I should need a dedicated machine, really. I've no
> problem running slimserver 6.5 with samba, apache, another MySQL instance,
> mail... on the same two year old Via C3/1GHz with 512MB ram. That machine
> does sometimes crash for unknown reasons. But it's been up for three
> months now, surviving quite a few slimserver installations.
>
> I'd bet most of the issues asking for a dedicated machine are due to some
> other influence.
>
>
I gotta agree with this. I look at the slimserver user on my server, and
it's using 150 MB of RAM and 2 percent average of the CPU, for all of its
services put together. During a scan, CPU use goes up to 20% or so for about
fifteen minutes (almost 14,000 tracks). It's the most important service on
the box, aside from low-impactors like routing, firewalling, squid, and
openvpn.

For comparison's sake, Firefox is using about the same amount of memory and
CPU on my XP laptop with 7 open tabs.

--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

pfarrell
2006-10-10, 15:05
JJZolx wrote:
> I meant a dedicated server, not necessarily a machine dedicated only to
> running SlimServer. Something not used as a desktop for playing
> Warcraft, watching porn, etc.

I've been doing this for years. My first SlimServer was an ancient PC
too slow to run Warcraft on. Maybe it ran Warcraft 1, but not Warcraft
2, StarCraft, etc. I thought it was a great use for an old crock
machine. Put it in the basement, ignore it. Play music with my slim
boxes all over the house.

The idea of having only one or two computers in a house is too weird for
me to consider.

A SlimServer box can skip the video card, fancy case, lights, etc.
No need for a DVD burnder, etc. Just use any old CPU and a half gig or
more of RAM, and be done.

Plus it gives you more reasons to install Ubuntu, Fedora, Mandriva, etc
over top of evil Windows.

Running a SlimServer on a desktop is possible, but why do it?

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Ben Sandee
2006-10-10, 15:19
On 10/10/06, Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
>
> Running a SlimServer on a desktop is possible, but why do it?


Just to play devil's advocate, how about anyone living in a studio apt or
college dorm. Granted, most of these people probably aren't buying SB's but
iPods.

That said, I've never even run SlimServer on anything but the headless
Debian box in my basement for the last three years.

Ben

stinkingpig
2006-10-10, 15:33
On 10/10/06, Ben Sandee <tbsandee (AT) gmail (DOT) com> wrote:
>
> On 10/10/06, Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
> >
> > Running a SlimServer on a desktop is possible, but why do it?
>
>
> Just to play devil's advocate, how about anyone living in a studio apt or
> college dorm. Granted, most of these people probably aren't buying SB's but
> iPods.
>
> That said, I've never even run SlimServer on anything but the headless
> Debian box in my basement for the last three years.
>
> Ben
>
>
Honestly, I doubt that a modern machine would have issues running it, even
with WoW going too :) Now if you're using a four or five year old computer
as your main desktop, that's another matter.
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

neurophyre
2006-10-10, 16:14
I beg to differ.

On my Slimserver box, which is a lowly PIII 600, the performance improvement from migrating the database to MySQL was DRAMATIC.

Despite the extra processes, memory etc, it was a very obvious improvement in speed of response. That was under SS 6.3, so the only variable was the database itself, the SS code was unchanged.

Funny, I came here to make a post asking if there's any way to improve performance on low-end machines. Hitting "play" on a directory with a few hundred files in it (say I want to listen to a shuffle of all my alternative music, or whatever) is absolutely glacial on my even more lowly 600MHz VIA Eden CPU (vaguely comparable to a 350MHz original Celeron, or so I've heard). The Squeezebox freezes hard for like 15 seconds until SlimServer can get itself together to build the playlist and start servicing UI requests again.

I really hope future releases will address low-end performance, as I suspect that a fair portion of users are running SlimServer on NAS type boxes that aren't exactly powerhouses. And those users tend to be the type that submit bug reports and patches and get things improved, I'd wager.

neurophyre
2006-10-10, 16:23
Honestly, I doubt that a modern machine would have issues running it, even
with WoW going too :) Now if you're using a four or five year old computer
as your main desktop, that's another matter.

Quite a few people don't WANT to have to dedicate a "modern machine" to SlimServer. They want it running on a NAS-type machine. I've got a 600MHz VIA C3 with 120MB available physical RAM that I use for NAS. Since I'm using it to store all my music and other files, since it's on 24/7 and since it does nothing else, it's the only logical choice to run SlimServer.

I know very well what "old" and "slow" machines are capable of, and you'd be surprised. SlimServer should not be as sluggish as it currently is on this machine.

Some of what people have said above seems to indicate that MySQL will lead to a performance increase on this machine. If so, that's great. Perl itself might be the next culprit to look at -- and why the heck SlimServer is chewing up SO much RAM.

Ben Sandee
2006-10-10, 16:25
On 10/10/06, neurophyre <
neurophyre.2fhiyz1160522101 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> I really hope future releases will address low-end performance, as I
> suspect that a fair portion of users are running SlimServer on NAS type
> boxes that aren't exactly powerhouses. And those users tend to be the
> type that submit bug reports and patches and get things improved, I'd
> wager.


NAS boxes are only going to get more powerful. I think SlimServer 6.5 is
far superior to 6.3 in all places except for memory-starved machines. With
memory as cheap as it is, the next generation NAS devices will be able to
handle SlimServer without any issue (assuming you can get it to run/deployed
-- that's a different issue!).

Ben

Ben Sandee
2006-10-10, 16:27
On 10/10/06, neurophyre <
neurophyre.2fhjfn1160522701 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> Jack Coates;145137 Wrote:
> > Honestly, I doubt that a modern machine would have issues running it,
> > even
> > with WoW going too :) Now if you're using a four or five year old
> > computer
> > as your main desktop, that's another matter.
>
> Quite a few people don't WANT to have to dedicate a "modern machine" to
> SlimServer. They want it running on a NAS-type machine. I've got a
> 600MHz VIA C3 with 120MB available physical RAM that I use for NAS.
> Since I'm using it to store all my music and other files, since it's on
> 24/7 and since it does nothing else, it's the only logical choice to run
> SlimServer.


Great. Add 256mb of RAM to that and you're all set. Otherwise you're just
asking too much of the box. I certainly do NOT want SlimDevices to spent
their time catering to a minority of people who won't spent $20 to upgrade
the RAM on their server.

Ben

stinkingpig
2006-10-10, 16:51
On 10/10/06, neurophyre <
neurophyre.2fhjfn1160522701 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> Jack Coates;145137 Wrote:
> > Honestly, I doubt that a modern machine would have issues running it,
> > even
> > with WoW going too :) Now if you're using a four or five year old
> > computer
> > as your main desktop, that's another matter.
>
> Quite a few people don't WANT to have to dedicate a "modern machine" to
> SlimServer. They want it running on a NAS-type machine. I've got a
>
>
I didn't say dedicated.

--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

pfarrell
2006-10-10, 18:29
Ben Sandee wrote:
>>> Running a SlimServer on a desktop is possible, but why do it?
>
>
> Just to play devil's advocate, how about anyone living in a studio apt
> or college dorm. Granted, most of these people probably aren't buying
> SB's but iPods.
>
> That said, I've never even run SlimServer on anything but the headless
> Debian box in my basement for the last three years.

Right, there may be a few people, but if you have a full blown PC
desktop, I don't see what a SqueezeBox buys. The beauty of the
SqueezeBox is not having a PC. Most folks will be happy with the sound
card in the motherboard. And if you are more picky, many sound card
upgrades are less than the price of the SqueezeBox.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

stinkingpig
2006-10-10, 19:12
On 10/10/06, Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
>
>
> Right, there may be a few people, but if you have a full blown PC
> desktop, I don't see what a SqueezeBox buys. The beauty of the
> SqueezeBox is not having a PC. Most folks will be happy with the sound
> card in the motherboard. And if you are more picky, many sound card
> upgrades are less than the price of the SqueezeBox.
>
>
Obviously a lot of people disagree, or there wouldn't be a market for SDI or
its many competitors. I know that when I plugged my first SliMP3 in to
replace the cable from my soundcard approach, I was completely blown away by
the sound quality improvement; this from someone who can't hear the
difference between a 192kbps MP3 and a CD.

Anyway, I do think there's a market opportunity out there for someone
building a SlimServer appliance -- it just needs to be a little beefier than
the QNAP, from the sound of things. I tend to delete any message with NAS in
it, but do the Infrants have enough horsepower to run SS properly? They seem
to generate fewer complaints.
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

smc2911
2006-10-10, 22:44
Funny, I came here to make a post asking if there's any way to improve performance on low-end machines. Hitting "play" on a directory with a few hundred files in it (say I want to listen to a shuffle of all my alternative music, or whatever) is absolutely glacial on my even more lowly 600MHz VIA Eden CPU (vaguely comparable to a 350MHz original Celeron, or so I've heard). The Squeezebox freezes hard for like 15 seconds until SlimServer can get itself together to build the playlist and start servicing UI requests again.
Building huge playlists like that can certainly be slow. If you want a shuffle on a big list of music, I'd suggest you look at erlands plugins here http://erland.homeip.net/download (primarily DynamicPlaylist and SQLPlaylist), which dynamically generates playlists in blocks of 10 tracks at a time. The performance is far better this way.

stinkingpig
2006-10-11, 08:30
On 10/10/06, smc2911 <smc2911.2fi10z1160545501 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> neurophyre;145151 Wrote:
> > Funny, I came here to make a post asking if there's any way to improve
> > performance on low-end machines. Hitting "play" on a directory with a
> > few hundred files in it (say I want to listen to a shuffle of all my
> > alternative music, or whatever) is absolutely glacial on my even more
> > lowly 600MHz VIA Eden CPU (vaguely comparable to a 350MHz original
> > Celeron, or so I've heard). The Squeezebox freezes hard for like 15
> > seconds until SlimServer can get itself together to build the playlist
> > and start servicing UI requests again.
> Building huge playlists like that can certainly be slow. If you want a
> shuffle on a big list of music, I'd suggest you look at erlands plugins
> here http://erland.homeip.net/download (primarily DynamicPlaylist and
> SQLPlaylist), which dynamically generates playlists in blocks of 10
> tracks at a time. The performance is far better this way.
>
>
Or use the built-in Random Play, which does the same thing.
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

chickenmagnet
2006-11-12, 13:25
I'd just like to add another request for a future option to use the sqlite3 back end. After installing slimserver 6.5 on my VIA M10000 machine with 256MB memory it became unusable for other work (ripping cds, etc.) due to swapping so I've had to order additional memory. I'm an experienced sqlite3 developer myself and I'm not aware of any memory overhead problems compared to other DBMS. Thanks!

Mister-E
2006-11-12, 15:32
Wow, if Slim went with MySQL for performance improvements, I think they failed on that one miserably...

smc2911
2006-11-12, 15:36
Or use the built-in Random Play, which does the same thing.
Mind you, erland's plugins provide far more flexibility than the built-in Random Play (e.g. play tracks you haven't played in a long time, rate tracks and then randomly play 4 and 5 star tracks, play unrated tracks, play jazz tracks you haven't played on the SB before, etc, etc).

John Stimson
2006-11-13, 15:32
It is transparent to the end user and that is all that counts.I wish! I had to upgrade to a newer version of my OS in order to get MySQL in a form that slimserver 6.5.0 was happy with. And it sure doesn't seem any snappier when dealing with full-catalogue shuffle or re-scanning the music library.