[slim] quick summary of 6.0 changes?

[Jeff Shanholtz]

I occasionally use nightlies and now that I have a "collection" (slimp3 and
a brand new sb), I'm curious about 6.0. Can anyone give a brief list of
significant changes in the 6.0 nightlies?

[kdf]

Quoting Jeff Shanholtz <jeffsubs-***@public.gmane.org>:

> I occasionally use nightlies and now that I have a "collection" (slimp3 and
> a brand new sb), I'm curious about 6.0. Can anyone give a brief list of
> significant changes in the 6.0 nightlies?
>

the main change is SQL.
secondary change is musicmagic integration

eventual plans include:
support for multiple/external data sources.
support for browse and filter based on teh SQL backend.
musicmagic integration via datastores

cheers,
kdf

[Dan Sully]

* kdf shaped the electrons to say...

>> I occasionally use nightlies and now that I have a "collection" (slimp3 and
>> a brand new sb), I'm curious about 6.0. Can anyone give a brief list of
>> significant changes in the 6.0 nightlies?
>
>the main change is SQL.

To be a little more correct - a built in RDBMS, SQL is just the query language.

>secondary change is musicmagic integration

6.0/CVS trunk also supports UTF-8 fully now, and has a Japanese web UI translation. (Thanks Ken!)

-D
--
<dr.pox> does whistling in the dark make me go blind faster?

[Jeffrey Gordon]

Dan Sully wrote:

> * kdf shaped the electrons to say...
>
>>> I occasionally use nightlies and now that I have a "collection"
>>> (slimp3 and
>>> a brand new sb), I'm curious about 6.0. Can anyone give a brief list of
>>> significant changes in the 6.0 nightlies?
>>
>>
>> the main change is SQL.
>
>
> To be a little more correct - a built in RDBMS, SQL is just the query
> language.
>
>> secondary change is musicmagic integration
>
>
> 6.0/CVS trunk also supports UTF-8 fully now, and has a Japanese web UI
> translation. (Thanks Ken!)
>
> -D

And for those of you on the list who do not gather what a
RDBMS(Relational Database Management System) is an can do for
Slimserver. It will greatly simplify the way we can access the data
stored of ALL our music. Right now without it some searches and browse
bys are not really possible because it is difficult to get to the data
in such a way.

Complex searches like what can be done in iTunes will be easier to
implement.

Now I am not a Slim dev. or or have inside info, just making a guess to
why they would want to use a RDBMS. Please correct me if I am wrong.

[Jeff Shanholtz]

On Fri, 31 Dec 2004 15:57:33 -0800, kdf wrote:

> the main change is SQL.
> secondary change is musicmagic integration
>
> eventual plans include:
> support for multiple/external data sources.
> support for browse and filter based on teh SQL backend.
> musicmagic integration via datastores

Thanks for answering. What exactly is multiple/external data sources? Do
you mean multiple music folders? Other kinds of audio sources (like "line
in" on the sound card)?

[kdf]

Quoting Jeff Shanholtz <jeffsubs-***@public.gmane.org>:

> On Fri, 31 Dec 2004 15:57:33 -0800, kdf wrote:
>
> > the main change is SQL.
> > secondary change is musicmagic integration
> >
> > eventual plans include:
> > support for multiple/external data sources.
> > support for browse and filter based on teh SQL backend.
> > musicmagic integration via datastores
>
> Thanks for answering. What exactly is multiple/external data sources? Do
> you mean multiple music folders? Other kinds of audio sources (like "line
> in" on the sound card)?

the abaility to add other sources for data, or other formats. Right now, the
server is handling queries using SQLLite, but MySQL is an option. It could
also be possible to import data from iTunes, MusicMagic, MoodLogic, MusicMatch
and yes, possibly multiple music folders. I am speaking only of metadata
sources, and not of audio data.

-kdf

[Keith O'Brien]

So do you have to install MySQL prior to loading 6.0? Or is everything self
contained. The box that I am running Slimserver on already has MySQL
loaded...will this cause a problem.

What has been the feedback of other regarding 6.0? Any major problems so
far?



-----Original Message-----
From: Jeff Shanholtz [mailto:jeffsubs-***@public.gmane.org]
Sent: Friday, December 31, 2004 11:36 PM
To: discuss-***@public.gmane.org
Subject: Re: [slim] quick summary of 6.0 changes?

On Fri, 31 Dec 2004 15:57:33 -0800, kdf wrote:

> the main change is SQL.
> secondary change is musicmagic integration
>
> eventual plans include:
> support for multiple/external data sources.
> support for browse and filter based on teh SQL backend.
> musicmagic integration via datastores

Thanks for answering. What exactly is multiple/external data sources? Do you
mean multiple music folders? Other kinds of audio sources (like "line in" on
the sound card)?

[kdf]

Quoting Keith O'Brien <keitheobrien-/***@public.gmane.org>:

> So do you have to install MySQL prior to loading 6.0? Or is everything self
> contained. The box that I am running Slimserver on already has MySQL
> loaded...will this cause a problem.

SQLlite is included in the install.

> What has been the feedback of other regarding 6.0? Any major problems so
> far?

Major problems are mostly past, but some may be to come as new features are
worked in. This is definately Alpha level and not to be taken on by anyone who
isn't prepared to run into a few quirks or even the occasional crash.

-kdf

[dean blackketter]

On Jan 2, 2005, at 9:47 PM, Keith O'Brien wrote:

> So do you have to install MySQL prior to loading 6.0? Or is
> everything self
> contained. The box that I am running Slimserver on already has MySQL
> loaded...will this cause a problem.
Nope, when finally shipped, the install/upgrade process shoudn't be any
more complicated than it is now, hopefully less.

> What has been the feedback of other regarding 6.0? Any major problems
> so
> far?
Well, it's still under development, so it's got a few bugs and
unfinished features (for example, searching with the remote is broken
today, but will probably be better tomorrow.)

SlimServer memory usage is lower, especially for large libraries and
many operations are much faster, such as web searching, browsing of
large libraries, etc...

There were a large number of bug reports and feature requests that
built up over time with the previous versions of SlimServer that were
all postponed until we could rework the infrastructure in SlimServer to
use a proper database backend. Now that this is in place, expect a lot
of fast improvement!

[Phillip Kerman]

> > What has been the feedback of other regarding 6.0? Any
> major problems
> > so
> > far?
> Well, it's still under development, so it's got a few bugs and
> unfinished features (for example, searching with the remote is broken
> today, but will probably be better tomorrow.)
>
> SlimServer memory usage is lower, especially for large libraries and
> many operations are much faster, such as web searching, browsing of
> large libraries, etc...
>
> There were a large number of bug reports and feature requests that
> built up over time with the previous versions of SlimServer that were
> all postponed until we could rework the infrastructure in
> SlimServer to
> use a proper database backend. Now that this is in place,
> expect a lot
> of fast improvement!


So... is this to say, the performance issues (in my case, just the dropouts)
is caused by large libraries or the flat database design of slim?

I'm looking forward to DB support... but, what I'm REALLY looking forward to
is improved stability/performance.

Thanks,
Phillip

[kdf]

Quoting Phillip Kerman <lists-o+I0KgJKNbax1f37qs3qIgC/***@public.gmane.org>:

> > > What has been the feedback of other regarding 6.0? Any
> > major problems
> > > so
> > > far?
> > Well, it's still under development, so it's got a few bugs and
> > unfinished features (for example, searching with the remote is broken
> > today, but will probably be better tomorrow.)
> >
> > SlimServer memory usage is lower, especially for large libraries and
> > many operations are much faster, such as web searching, browsing of
> > large libraries, etc...
> >
> > There were a large number of bug reports and feature requests that
> > built up over time with the previous versions of SlimServer that were
> > all postponed until we could rework the infrastructure in
> > SlimServer to
> > use a proper database backend. Now that this is in place,
> > expect a lot
> > of fast improvement!
>
>
> So... is this to say, the performance issues (in my case, just the dropouts)
> is caused by large libraries or the flat database design of slim?
>
> I'm looking forward to DB support... but, what I'm REALLY looking forward to
> is improved stability/performance.

If you want stability, use 5.4.1. write bug reports on that based on STABILITY
ONLY. That is the focus of 5.4.1 and that stream. 6.0 is for speed of data
handling. dropouts might be reduced, but they are really rather a
streaming/network problem that may see some improvement as data handling speeds
up.

Stability does not apply to 6.0 at this time, and for good reason. These
features need to be brought in. They are large and need testing. For now,
stability and performance are not appropriate partners.

honestly, the constant flogging of pet issues is really not much help at this
point. It may feel better fro the venting, but really never helps the overall
effort very much. This isn't directed at you, but speaking for myself, reading
this list has tended to suck the motivation right out of me in the last few
weeks. Assuming I'm rather average for the typical independent contributor,
that's a bad thing. There is list, fortunately small, of people who, to my
mind, who did contribute a lot, but have gone silent of late. I do find myself
wondering why.

The frank reality is that the dropouts are known, and may or may not be solved
by the db. they are not, however, the goal of the db. Many people, including
myself have no problems with dropouts. I expect the ultimate solution for that
is a more robust reporting structure for streaming performance so that network
issues can be better detected and resolved. Heck, for all I know 802.11 may
just not be solid enough to guarantee what it claims in all cases.

probably not the response you wanted, but hopefully valuable in some sense
regardless.

cheers,
kdf

[Phillip Kerman]

First... I was reacting to this:

>Now that this is in place,
> > expect a lot
> > of fast improvement!

..not so much just a chance to vent.



> If you want stability, use 5.4.1. write bug reports on that
> based on STABILITY
> ONLY. That is the focus of 5.4.1 and that stream. 6.0 is
> for speed of data
> handling. dropouts might be reduced, but they are really rather a
> streaming/network problem that may see some improvement as
> data handling speeds
> up.

Okay... but is 5.4.1 released yet? I'm not really into doing the nightly
builds any more.


I do think my questions are pointed at making the general suggestion that my
pet issues (and others) are given some priority. All I have is empirical
data that the 5.4 release changed performance slightly. It could easily be
something else... but I look at the sincerely valuable feature of RSS and
just have to wonder if that comes at the expense of issues that I would
consider more primary.

I really don't intend to sound like I'm harping on stuff... certainly don't
want to reduce anyone's enthusiasm. But... like I say, I was just asking
because of Dean's words above.

Thanks,
Phillip

[kdf]

Quoting Phillip Kerman <lists-o+I0KgJKNbax1f37qs3qIgC/***@public.gmane.org>:

> First... I was reacting to this:
>
> >Now that this is in place,
> > > expect a lot
> > > of fast improvement!
>
> ..not so much just a chance to vent.

of course. but of course, that statement was in reference to 6.0, which is
currently in alpha test (essentially) and most likely will not be an official
release for some time.

> > If you want stability, use 5.4.1. write bug reports on that
> > based on STABILITY
> > ONLY. That is the focus of 5.4.1 and that stream. 6.0 is
> > for speed of data
> > handling. dropouts might be reduced, but they are really rather a
> > streaming/network problem that may see some improvement as
> > data handling speeds
> > up.
>
> Okay... but is 5.4.1 released yet? I'm not really into doing the nightly
> builds any more.

no, it isn't. however, that too, is in response to other user feedback.
Releasing is met with harsh feedabck if its even slightly less than perfect.
The only way to get that even close is to make it available to all those who
can offer some help to make it as stable as possible. There are always a large
group of people who say nothing until the release, and then are loudly upset
that their particular problem hasnt' been solved. oddly, some of those
complaints are the first we hear of them, or as yet unreproducable by those who
are working on the code.

>
>
> I do think my questions are pointed at making the general suggestion that my
> pet issues (and others) are given some priority. All I have is empirical
> data that the 5.4 release changed performance slightly. It could easily be
> something else... but I look at the sincerely valuable feature of RSS and
> just have to wonder if that comes at the expense of issues that I would
> consider more primary.

you and I both. However, my feelings about fixing bugs are moderated by my
experience as an engineer. Every day I see situations where the needs of
several directions are priority. Whether it be marketing, or support or
investors, priorities change. Your issue is dropouts, but there are just as
many users who will 'hint' that they will return their squeezebox unless their
wife gets instant access to news and internet radio. that's just one example.
yes, its the squeeky wheel. I realise that, but I dont have to like it :) My
dislike for it, is something I'm free to voice, just as much as your
dissatisfaction over dropouts.
>
> I really don't intend to sound like I'm harping on stuff... certainly don't
> want to reduce anyone's enthusiasm. But... like I say, I was just asking
> because of Dean's words above.

Again, it wasnt' directed at you. In fact, it is more that you have offered a
more reasonable stance, that I bother to voice mine. I have no desire to take
part in religious flame wars. You will see fast improvement in 6.0, as Dean
said, but it will not be stable. In fact, as fo right now cvs will not
complete a rescan for me without going into an infinite loop. However, at the
same time, with my own tweaking to force a bypasss of the loop, I can see other
great gains, like the browsedb feature. Browse by year is added and the other
browse modes seem much faster. My 'fix', however, currently kills CUE sheets.

In summary...the definition of improvement is subjective when it comes to 6.0.
Lots of new fixes, but not all that stable for now. fast improvements, yes.
however, if your personal top priority is streaming....not so much.

-kdf

[Marc Sherman]

kdf wrote:
>
> In fact, as fo right now cvs will not complete a rescan for me
> without going into an infinite loop. However, at the same time, with
> my own tweaking to force a bypasss of the loop, I can see other great
> gains, like the browsedb feature. Browse by year is added and the
> other browse modes seem much faster. My 'fix', however, currently
> kills CUE sheets.
>
> In summary...the definition of improvement is subjective when it
> comes to 6.0. Lots of new fixes, but not all that stable for now.
> fast improvements, yes. however, if your personal top priority is
> streaming....not so much.

Thanks for the insight into the current state of the 6.0 branch, kdf.
Is there a public bug database where these issues can be browsed and
tracked by interested users (particularly ones with hacking skills who
might be motivated to help)?

BTW, how many Debian users are there here? I've been thinking about
picking up the Debian packaging. This'll be my first package, so if
anyone has more experience at it than I do, please step up. :) Bruno
(the current maitainer, who's got 4.2.6 in the archive as slimp3, and
5.2.1 on a private website waiting for sponsorship for 5 months now) has
OK'd me taking over the package.

- Marc

[Marc Sherman]

Marc Sherman wrote:
>
> Thanks for the insight into the current state of the 6.0 branch, kdf. Is
> there a public bug database where these issues can be browsed and
> tracked by interested users (particularly ones with hacking skills who
> might be motivated to help)?

Duh. bugs.slimdevices.com. Sorry, that'll teach me to post before a>
reading the entire thread, and b> finishing my morning coffee.

- Marc

[Craig Eales]

Marc,

I am a debian user (sarge - testing 2.6 kernel) - however I have no
experience of the package mechanism (apart from as a consumer). But I
am more than willing to be a tester - give me a shout when you have
somehting to try.

Craig

On Tue, 04 Jan 2005 08:04:32 -0500, Marc Sherman <msherman-***@public.gmane.org> wrote:
> kdf wrote:
> >
> > In fact, as fo right now cvs will not complete a rescan for me
> > without going into an infinite loop. However, at the same time, with
> > my own tweaking to force a bypasss of the loop, I can see other great
> > gains, like the browsedb feature. Browse by year is added and the
> > other browse modes seem much faster. My 'fix', however, currently
> > kills CUE sheets.
> >
> > In summary...the definition of improvement is subjective when it
> > comes to 6.0. Lots of new fixes, but not all that stable for now.
> > fast improvements, yes. however, if your personal top priority is
> > streaming....not so much.
>
> Thanks for the insight into the current state of the 6.0 branch, kdf.
> Is there a public bug database where these issues can be browsed and
> tracked by interested users (particularly ones with hacking skills who
> might be motivated to help)?
>
> BTW, how many Debian users are there here? I've been thinking about
> picking up the Debian packaging. This'll be my first package, so if
> anyone has more experience at it than I do, please step up. :) Bruno
> (the current maitainer, who's got 4.2.6 in the archive as slimp3, and
> 5.2.1 on a private website waiting for sponsorship for 5 months now) has
> OK'd me taking over the package.
>
> - Marc
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss
>

[Robin Bowes]

kdf wrote:
>
> The frank reality is that the dropouts are known, and may or may not be solved
> by the db.

If I might chime in here...

It is my feeling that dropouts will *not* be completely solved by the
new DB backend. In my experience, apart from flaky network issues,
dropouts are caused by the slimserver process being unable to maintain
the audio stream when it gets bogged down doing other things. This may
be improved slightly by cutting down on the time taken to perform
certain activities, e.g. scanning, searching, etc., but the underlying
problem will remain.

Someone on this list (hint: he recently joined the slim team) has used
the following .sig in the past:

"You can usually recover from production flaws...but you can never
recover from a bad design".

It is my firm belief that the whole architecture of slimserver needs
overhauling in such a way that the audio streaming code is isolated and
can be given priority. I'm not sure what this might involve; threading?
spawning separate processes? something else? But I'm convinced that this
is necessary.

All the other stuff really is eye (ear?) candy and should take a back
seat to getting the basics right.

Now, whilst I'm happy to hack at some of the code to improve certain
things, this is such a fundamental change that it really needs to come
from the top, so to speak. Is there any chance that this could be given
priority?

Talking of priority, I'd also like to see some sort of response to the
bugs/enhancement requests posted at bugs.slimdevices.com. Would it be
possible to build them into some sort of road map and plan to get them
into new releases?

Talking of roadmap, in my experience quality of software improves
greatly if developers are working to some sort of roadmap. I suggest
that a medium-term plan is drawn up listing what changes are planned for
successive releases of slimserver. This gives developers targets to aim
for and ensures the important issues are addressed rather than being
overlooked for new, more sexy changes.

Please take these comments as positive criticism, not a moan or a rant
I want to see slimserver improve and I will help all I can.

R.

[kdf]

Quoting Robin Bowes <robin-lists-uu/***@public.gmane.org>:

> kdf wrote:
> >
> > The frank reality is that the dropouts are known, and may or may not be
> solved
> > by the db.
>
> If I might chime in here...
and if I might chime in....(as if I woudlnt ;)
>
> Now, whilst I'm happy to hack at some of the code to improve certain
> things, this is such a fundamental change that it really needs to come
> from the top, so to speak. Is there any chance that this could be given
> priority?

eventually, I'm sure it will. one thing at a time. everyone going on about
their own personal peeve, again. if the response was truly equal to all in
real time, nothing would get done. the db backend is an old issue and long
overdue. after that, other issues can then be taken on with much greater
focus. or course, I'll imply/ignore the disclaimer for those to want to be
upset about the particular choice of query algorithm.


> Talking of priority, I'd also like to see some sort of response to the
> bugs/enhancement requests posted at bugs.slimdevices.com. Would it be
> possible to build them into some sort of road map and plan to get them
> into new releases?

you have the wiki for that. there is a roadmap there. the bug also have a
target milestone option to each, which, when applicable, are used.

>
> Talking of roadmap, in my experience quality of software improves
> greatly if developers are working to some sort of roadmap. I suggest
> that a medium-term plan is drawn up listing what changes are planned for
> successive releases of slimserver. This gives developers targets to aim
> for and ensures the important issues are addressed rather than being
> overlooked for new, more sexy changes.

again, check the wiki. However, I can empathise with you on one level, in that
development does tend to follow rants sometimes more than plan. of course,
this can end up being counter productive, in that speaking for change is also
expecting a response to rant.
>
> Please take these comments as positive criticism, not a moan or a rant
> I want to see slimserver improve and I will help all I can.
>
excellent, and welcomed.

I use 'rant' as a term for emotional discussion. it's not a negative term (at
least in this case). in many respects, I'm with you. In other respects, I'm
canadian (read apathetic, perhaps), so I wait and comply vs pushing for change.
As Slim Devices grows, with more full time, employed developers, this will
change. However, with a small group, its just not fair to expect/demand every
reponse to be instant. DB may not be the top priority for all, but focussing
on it, and getting it done is still good for all concerned. Then, at least,
that part will work and we can all then focus on the next big thing. What gets
priority is a simple choice. Not everyone will agree to a given choice.

As everyone here knows, I'm very vocal and opinionated. Those opinions are not
lost simply becuase the SlimDevices focus is elsewhere. I just choose to put
my efforts where they lead. Right now, that's the DB. overall UI, streaming
reliability, audio quality are all valid issues, but are just something to deal
with after the current chosen focus. When the time comes, I'll be just as
vocal about those :)

[Robin Bowes]

kdf wrote:
> Quoting Robin Bowes
> <robin-lists-uu/***@public.gmane.org>:
>
> eventually, I'm sure it will. one thing at a time. everyone going
> on about their own personal peeve, again. if the response was truly
> equal to all in real time, nothing would get done.

Hence my suggestion of a formal prioritisation of issues and a roadmap.

> the db backend is an old issue and long overdue. after that, other
> issues can then be taken on with much greater focus. or course, I'll
> imply/ignore the disclaimer for those to want to be upset about the
> particular choice of query algorithm.

:)

One thing I would say is that the "db backend will make everying better"
response has been wheeled out on several occasions and I'm concerned
that this is setting false expectation. For one, v6.0 is some way off
official release although we have no target date (it's that roadmap
thing again).

>> Talking of priority, I'd also like to see some sort of response to
>> the bugs/enhancement requests posted at bugs.slimdevices.com. Would
>> it be possible to build them into some sort of road map and plan to
>> get them into new releases?
>
>
> you have the wiki for that. there is a roadmap there. the bug also
> have a target milestone option to each, which, when applicable, are
> used.

I wasn't aware of the wiki. That looks like a step in the right
direction. However, the slimserver page has not been updated since 7th
Aug 2004.

Also, only 14 out of 352 bugs have Target Milestone changed after
01/01/1970 (this was the only way I could work out to show all bugs with
a target milestone assigned).

>> Talking of roadmap, in my experience quality of software improves
>> greatly if developers are working to some sort of roadmap. I
>> suggest that a medium-term plan is drawn up listing what changes
>> are planned for successive releases of slimserver. This gives
>> developers targets to aim for and ensures the important issues are
>> addressed rather than being overlooked for new, more sexy changes.
>
>
> again, check the wiki. However, I can empathise with you on one
> level, in that development does tend to follow rants sometimes more
> than plan. of course, this can end up being counter productive, in
> that speaking for change is also expecting a response to rant.

Again, this shows the value of a roadmap and a more organised
development schedule.

>> Please take these comments as positive criticism, not a moan or a
>> rant I want to see slimserver improve and I will help all I can.
>>
>
> excellent, and welcomed.
>
> I use 'rant' as a term for emotional discussion. it's not a negative
> term (at least in this case). in many respects, I'm with you. In
> other respects, I'm canadian (read apathetic, perhaps), so I wait and
> comply vs pushing for change.

Ah, well I'm a Project Manager by trade so my job is to make things
happen. The suggestions I have made are simple techniques that work and
get things done.

> As Slim Devices grows, with more full
> time, employed developers, this will change. However, with a small
> group, its just not fair to expect/demand every reponse to be
> instant.

That's not what I'm getting at. I just want to see issues prioritised
and addressed in priority order.

> DB may not be the top priority for all, but focussing on
> it, and getting it done is still good for all concerned. Then, at
> least, that part will work and we can all then focus on the next big
> thing. What gets priority is a simple choice. Not everyone will
> agree to a given choice.

From the wiki:

"The main goals of the SlimServer project in the near term, in rough
priority order, are:

* Stability and performance - No crashers, quick startup, no skips,
less memory usage.
* Ease of setup and use - Tackle the issues that make it hard for
newbies to install and use the product.
* More audio sources - Do what it takes - formats, DRM, integration
with external audio providers - to make sure our users are not limited
in their listening options.
* Large library support - Ensure that we make it easy to manage and
use large music collections.
* Significant differentiating or parity features - Continue to make
sure that SlimServer and Slim Devices hardware are the best options out
there."

However, I don't see these priorities reflected in the work that is
being done.

> As everyone here knows, I'm very vocal and opinionated. Those
> opinions are not lost simply becuase the SlimDevices focus is
> elsewhere. I just choose to put my efforts where they lead. Right
> now, that's the DB. overall UI, streaming reliability, audio quality
> are all valid issues, but are just something to deal with after the
> current chosen focus. When the time comes, I'll be just as vocal
> about those :)

You see, I would say that's a shame. You obviously have a lot to offer
and are are v. knowledgeable about slimserver. If I were managing your
effort I would attempt to get you to work in areas that address the
stated priorities of the project.

As I said above, I want to help and I am pursuing a lead which might
help with the architecture issues. It's very embryonic at the moment and
might not come to anything but I'll go public when I've gathered a
little more information.

Cheers,

R.

[kdf]

Quoting Robin Bowes <robin-lists-uu/***@public.gmane.org>:

> kdf wrote:
> > Quoting Robin Bowes
> > <robin-lists-uu/***@public.gmane.org>:
> >
> > eventually, I'm sure it will. one thing at a time. everyone going
> > on about their own personal peeve, again. if the response was truly
> > equal to all in real time, nothing would get done.
>
> Hence my suggestion of a formal prioritisation of issues and a roadmap.

The basics of one are around. Maintaining it seems to be the catch. That, and
saying 'no' to requests that do not fit to the roadmap.

> > the db backend is an old issue and long overdue. after that, other
> > issues can then be taken on with much greater focus. or course, I'll
> > imply/ignore the disclaimer for those to want to be upset about the
> > particular choice of query algorithm.
>
> :)
>
> One thing I would say is that the "db backend will make everying better"
> response has been wheeled out on several occasions and I'm concerned
> that this is setting false expectation.

me too. But there are a list of bugs/feature requests that are only feasible
with the db backend. Other issues may show improvement, but its hard to tell
until the db matures a bit. some early reports from some power users are
encouraging, but there is a long way to go. hence no date, yet.

> I wasn't aware of the wiki. That looks like a step in the right
> direction. However, the slimserver page has not been updated since 7th
> Aug 2004.

There's that maintenance thing :)

> Also, only 14 out of 352 bugs have Target Milestone changed after
> 01/01/1970 (this was the only way I could work out to show all bugs with
> a target milestone assigned).

The option is there, and it was used specifically for one release. 14 of 352
would seem to only take into account the open bugs. I totally agree that there
should be more use of the target milestone, but at least the option has been
made available.

>
> >> Talking of roadmap, in my experience quality of software improves
> >> greatly if developers are working to some sort of roadmap. I
> >> suggest that a medium-term plan is drawn up listing what changes
> >> are planned for successive releases of slimserver. This gives
> >> developers targets to aim for and ensures the important issues are
> >> addressed rather than being overlooked for new, more sexy changes.
> >
> >
> > again, check the wiki. However, I can empathise with you on one
> > level, in that development does tend to follow rants sometimes more
> > than plan. of course, this can end up being counter productive, in
> > that speaking for change is also expecting a response to rant.
>
> Again, this shows the value of a roadmap and a more organised
> development schedule.

well, I can only speak to what has been made public. Slim Devices is incredibly
open with information, but I expect that there is a lot more that doesn't
really make it to the public venues. This is not to suggest a flaw, but just
the nature of things. Even in a projet group of 6 engineers, not every
conversation or decision is immediately brought to the attention of all 6.
Having it all public would be nice, but it does take someone away from the
actual writing and testing of slimserver.


> That's not what I'm getting at. I just want to see issues prioritised
> and addressed in priority order.
>
> > DB may not be the top priority for all, but focussing on
> > it, and getting it done is still good for all concerned. Then, at
> > least, that part will work and we can all then focus on the next big
> > thing. What gets priority is a simple choice. Not everyone will
> > agree to a given choice.
>
> From the wiki:
>
> "The main goals of the SlimServer project in the near term, in rough
> priority order, are:
>
> * Stability and performance - No crashers, quick startup, no skips,
> less memory usage.
> * Ease of setup and use - Tackle the issues that make it hard for
> newbies to install and use the product.
> * More audio sources - Do what it takes - formats, DRM, integration
> with external audio providers - to make sure our users are not limited
> in their listening options.
> * Large library support - Ensure that we make it easy to manage and
> use large music collections.
> * Significant differentiating or parity features - Continue to make
> sure that SlimServer and Slim Devices hardware are the best options out
> there."
>
> However, I don't see these priorities reflected in the work that is
> being done.

Stability and performance: the db backend has been a major issue for a long time
and has always been about performance. its not reflected in the results yet,
but those who first began putting out the suggestions/requests/demands for a db
all claim that a db is the only way to get the level of performance users want
from slimserver.

Ease of setup: well, I'm hard pressed to think of specific examples for this.
Of course, I've never used the 'easy' installs. Most certainly, I have seen
default values and menu arrangements change in recent months with the intent of
making things easier to use.

more audio sources: APE has been added recently. DRM is something we are less
likely to hear about in progress reports. That kind of thing falls more into
the realm of legal haggling. AlienBBC keeps expanding its ability to handle
more streams. The whole Internet Radio featureset is also very recent and
subsequent to those entries in the wiki.

Large Library Support: the db is a prerequisite to this. The browsedb interface
came in yesterday. This begins to show how the data can be manipulated and
displayed. Also, since this wiki entry, features have been added to edit
playlists.

Parity Features: this is a very open item. I tend to think that slimserver is a
superb product, so its hard to single out specific features that must be added
in order to be more like another product. However, the bugs list is there for
anyone to file feature requests. Some of those requests fall into this
category.

> > As everyone here knows, I'm very vocal and opinionated. Those
> > opinions are not lost simply becuase the SlimDevices focus is
> > elsewhere. I just choose to put my efforts where they lead. Right
> > now, that's the DB. overall UI, streaming reliability, audio quality
> > are all valid issues, but are just something to deal with after the
> > current chosen focus. When the time comes, I'll be just as vocal
> > about those :)
>
> You see, I would say that's a shame. You obviously have a lot to offer
> and are are v. knowledgeable about slimserver. If I were managing your
> effort I would attempt to get you to work in areas that address the
> stated priorities of the project.

Well, I'd say we probably share the same ideals, but are approaching from
different perspectives. I feel I AM contributing to the priority areas.
Performance and Stability are umbrella issues. The database is the current,
specific task to address performance. I also feel that debating issues like
this are also a part of addressing performance. I will admit that my
particular stance on documentation doesn't place a very high priority on
formally writing out, for all to see, what I'm doing and why.

>
> As I said above, I want to help and I am pursuing a lead which might
> help with the architecture issues. It's very embryonic at the moment and
> might not come to anything but I'll go public when I've gathered a
> little more information.

sounds great. The desire to help is always a good thing. I've dumped just
about everything I know at you already, save to suggest joining the checkins
mailing list. Its just the cvs checkin notices, but the comments can sometimes
offer a good view of the intent behind the changes.

-kdf

[Kevin Hawkins]

Robin Bowes wrote:

>
> It is my firm belief that the whole architecture of slimserver needs
> overhauling in such a way that the audio streaming code is isolated
> and can be given priority. I'm not sure what this might involve;
> threading? spawning separate processes? something else? But I'm
> convinced that this is necessary.
>

I too suffer the big dropout problems on 5.4.1 (XP) and hence have
been playing with v6 , accepting its quirks and missing features and
that on a minute by minute basis it may or may not work as expected.
That is the nature of the beast.
I had believed that a separate threading of the playback process was
to be an integral part of the v6 server but from this thread I am
guessing it's not. :-( Like Robin I think this is an important change
that must be made to the architecture to safeguard a satisfactory user
experience. I hope it remains a top priority issues as to me dropouts
and stalls in playback is an absolute killer to the user experience.
These dropouts changed me from being delighted to frustrated in my 8
players.
Having said that: I currently experience major dropouts (over 15
minutes on a search) using 5.41 - and periodic glitches of 10 secs or
so. Often 5.41 which happily plays for 3 days or so will then just die.
All this has now gone with V6 :-) and perhaps the processing relief that
the new SQL DB provides is sufficiently large that the issue is
resolved. For me I'm cautiously optimistic about v6 now and every day,
well most ;-) it improves. Searches previously at 14 mins are now down
to 5 seconds and I can play constantly with no glitches. Half the other
'features' are missing or still in their infancy but for me
uninterrupted playback, the key feature, has restored my faith and
enthusiasm. I can't recommend any users switch to v6 as yet as it is
still very very early in its days but at least there is light at the end
of the tunnel.
If I interpret what KDF is saying the previous RAM based data
staructures were a millstone and the major contributor to revealing
threading architecture issues that caused stalls. So fixing the DB may
well place the playback threading issue to 'hidden' again. Of course
fixing that too would be a double benefit.
So I'm smiling again, and 'quiet' currently, counting on and
cautiously optimistic that with V6 Slim will get back to the great
experience it was back in the V4 days - but augmented by all the 'whiz
bang' enhancements since then that make owning a Slim product so much
more exciting than any other audio playback solution I can think of.

Kevin

[Michael Amster]

Robin:

I agree with your assessment. I look at this application and see
something dying to be a threaded architecture. I understand that Perl
threading is not there yet - it's really too bad. I wonder if a hybrid
Java/Perl mechanism would work? I have written Java code for years and
would help port the streaming of data to this - it would be a shame to
waste the man years in the current code base, so I would be interested
in hearing if there were a way to partition some of these tasks like
serving audio streams and maybe rescanning the music folders to separate
encapsulated threads/processes. I guess this discussion should move to
the developer list.

-MA

Robin Bowes wrote:

> kdf wrote:
>
>>
>> The frank reality is that the dropouts are known, and may or may not
>> be solved
>> by the db.
>
>
> If I might chime in here...
>
> It is my feeling that dropouts will *not* be completely solved by the
> new DB backend. In my experience, apart from flaky network issues,
> dropouts are caused by the slimserver process being unable to maintain
> the audio stream when it gets bogged down doing other things. This may
> be improved slightly by cutting down on the time taken to perform
> certain activities, e.g. scanning, searching, etc., but the underlying
> problem will remain.
>
> Someone on this list (hint: he recently joined the slim team) has used
> the following .sig in the past:
>
> "You can usually recover from production flaws...but you can never
> recover from a bad design".
>
> It is my firm belief that the whole architecture of slimserver needs
> overhauling in such a way that the audio streaming code is isolated
> and can be given priority. I'm not sure what this might involve;
> threading? spawning separate processes? something else? But I'm
> convinced that this is necessary.
>
> All the other stuff really is eye (ear?) candy and should take a back
> seat to getting the basics right.
>
> Now, whilst I'm happy to hack at some of the code to improve certain
> things, this is such a fundamental change that it really needs to come
> from the top, so to speak. Is there any chance that this could be
> given priority?
>
> Talking of priority, I'd also like to see some sort of response to the
> bugs/enhancement requests posted at bugs.slimdevices.com. Would it be
> possible to build them into some sort of road map and plan to get them
> into new releases?
>
> Talking of roadmap, in my experience quality of software improves
> greatly if developers are working to some sort of roadmap. I suggest
> that a medium-term plan is drawn up listing what changes are planned
> for successive releases of slimserver. This gives developers targets
> to aim for and ensures the important issues are addressed rather than
> being overlooked for new, more sexy changes.
>
> Please take these comments as positive criticism, not a moan or a rant
> I want to see slimserver improve and I will help all I can.
>
> R.
>
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss

[John S J Anderson]

Michael Amster <mamster-***@public.gmane.org> writes:

> Robin:
>
> I agree with your assessment. I look at this application and see
> something dying to be a threaded architecture.

An almost completely off-topic aside: Tridge on threads:

What is it about the word "thread" that people find so damn sexy?
Maybe it needs a name change
"slow-as-hell-no-memory-protection-locks-dont-work" API might be
suitable, but I suspect the standards committees wouldn't like
that one.

The MMU was added to CPUs for a very good reason. Why is it so
hard to understand that trying to avoid it is a bad idea?

Have you thought about the orders of magnitude here? With process
switching on a modern CPU you basically have to swap one more
register. Thats one extra instruction. Modern CPUs have nanosecond
cycle times.

Now, some CPUs also need to do an extra tlb flush or equivalent,
but even that is cheap on all but the worst CPUs.

Compare this to the work that a file server has to do in
responding to a packet. Say its a SMBread of 4k. That is a 4k copy
of memory. Memory is slow. Typically that SMBread will take tens
of thousands of times longer than the context switch time.

But by saving that nanosecond you will make the read() system call
slower! Why? Because in the kernel the file descriptor number
needs to be mapped from a integer to a pointer to a
structure. That means looking up a table. That table needs to be
locked. If you have 100 threads doing this then they all lock the
_same_ structure, so you get contention, and suddenly your 16 cpu
system is not scaling any more. With processes they lock
_different_ structures, so no contention, so better scaling.

This lock contention can be fixed with some really smart
programming (like using RCU), and recently that has been done in
Linux. That's one reason why Linux sucks less than other systems
for threads.

Try thinking about this. How do threads do their IPC? They use the
same system calls and mechanisms that are available to
processes. The difference is that in a threads library these
mechanisms are wrapped into a nice API that makes it convenient to
do IPC really easily. You can do exactly the same types of IPC
with processes, you just need to write a bit more code.

For many things, perhaps even for some file server applications,
that extra convenience is worthwhile. Convenience means simpler
code which means fewer bugs. So I'm not saying to never use
threads, I'm just trying to kill this persistent meme that says
threads are somehow faster. That's like believing in the tooth
fairy.

(via <http://sourcefrog.net/weblog/software/languages/java/java-threads.html>)

cheers,
john.
--
"We're not left-wing or right-wing, we're up-wing."
- John Gilmore, EFF co-founder, in reference to the Electronic Frontier
Foundation's politics.

[Jack Coates]

kdf wrote:
...

> The frank reality is that the dropouts are known, and may or may not be solved
> by the db. they are not, however, the goal of the db. Many people, including
> myself have no problems with dropouts. I expect the ultimate solution for that
> is a more robust reporting structure for streaming performance so that network
> issues can be better detected and resolved. Heck, for all I know 802.11 may
> just not be solid enough to guarantee what it claims in all cases.

This is my opinion as well. 802.11b as a protocol and from a gear
quality perspective is just not there for streaming. It's great when it
works, but the factors that can make it not work are legion.

Open question, maybe a write up on how to use SoftSqueeze to pre-check a
site's wireless streaming capabilities is in order?

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

[Steve Baumgarten]

Jack Coates wrote:

> This is my opinion as well. 802.11b as a protocol and from a gear
> quality perspective is just not there for streaming. It's great when it
> works, but the factors that can make it not work are legion.

This is true. There's no QoS (Quality of Service) for 802.11b or 802.11g
for that matter. This is an issue currently being worked on for future
wireless protocols, but it was never thought about for 802.11b. As a
result, things usually work fine. Usually. But sometimes there are minor
glitches. It goes with the territory.

Just the other night I had the 802.11b network connection on my laptop
drop for a few seconds and then reconnect. Why? I was near an AP and had
great signal strength. No one used the microwave or picked up a phone.
Who knows? It happens.

When I get the occasional dropout streaming FLAC->PCM on my Squeezebox,
I tend more to chalk it up to general 802.11b voodoo than any problem
inherent with the Slimserver. (Note that this is not true for dropouts
caused by inordinate server activity, like when you do a search. On the
other hand, this is exactly the area of the product currently being
worked on, hopefully leaving only 802.11b voodoo the sole reason for
future dropouts.)

In terms of the product itself, only a bigger buffer on the Squeezebox
might help. I am getting what I consider to be my money's worth out of
the product as it stands; should Slimdevices release a new version of
the Squeezebox with additional features (bigger buffer; more native
protocols; support for DRM; whatever), I'd buy one -- just as I'd
consider buying a new iPod to replace the iPod Mini I'm currently
enjoying (and getting my money's worth out of, despite all its
limitations). But for now I realize there are certain limitations, none
of which seem to be the end of the world to me, and only some of which
are related to the product itself. (Though obviously other people's
mileage will vary.)

SBB




Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.

[Brian Abbott, ACA Systems]

On a related note, why wasn't 802.11g adopted for the SB? The small extra
cost would have been worth it ...

Steve Baumgarten wrote:
> Jack Coates wrote:
>
>> This is my opinion as well. 802.11b as a protocol and from a gear
>> quality perspective is just not there for streaming. It's great when
>> it works, but the factors that can make it not work are legion.

============
Brian Abbott

ACA Systems
============

[kdf]

Quoting "Brian Abbott, ACA Systems" <brian-***@public.gmane.org>:

> On a related note, why wasn't 802.11g adopted for the SB? The small extra
> cost would have been worth it ...

802.11g requires a faster and wider bus. It would have meant a different CPU as
well. Likely that would have been a much greater cost difference than a simple
change of pc card.

-kdf

[Robin Bowes]

kdf wrote:
> Quoting "Brian Abbott, ACA Systems" <brian-***@public.gmane.org>:
>
>
>>On a related note, why wasn't 802.11g adopted for the SB? The small extra
>>cost would have been worth it ...
>
>
> 802.11g requires a faster and wider bus. It would have meant a different CPU as
> well. Likely that would have been a much greater cost difference than a simple
> change of pc card.

I think it would be worth pointing out that the wired interface on the
SB is only 10Base-T, i.e. 10Mb/s. Wireless 11b is theoretically 11Mb/s
i.e. more than the wired port!

Both of these have more than enough bandwidth to stream raw PCM/wav to
the Squeezebox. For example:

A stereo wav file sampled at 44.1kHz (i.e. CD quality) will consist of
44,100 pairs of 16-bit samples for every second of music, so the
bit-rate required is 44,100 x 2 x 16 = 1.4Mb/s.

Both the wired and wireless interfaces of the Squeezebox have more than
enough capacity to cope with this. 11g may be a more robust protocol or
have better range but it wouldn't make any difference in terms of bandwidth.

R.

[Brian Abbott, ACA Systems]

I seem to recall that the 'official' position on streaming FLAC/WAV is that
'it might work if the connection is good, but if not you can always attach a
8011.g access point to the SP's rj45 ...'

Robin Bowes wrote:
>
> A stereo wav file sampled at 44.1kHz (i.e. CD quality) will consist
> of 44,100 pairs of 16-bit samples for every second of music, so the
> bit-rate required is 44,100 x 2 x 16 = 1.4Mb/s.
>
> Both the wired and wireless interfaces of the Squeezebox have more
> than enough capacity to cope with this. 11g may be a more robust
> protocol or have better range but it wouldn't make any difference in
> terms of bandwidth.
>
> R.
>
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss

============
Brian Abbott

ACA Systems
============

[Jack Coates]

ron thigpen wrote:
...

>
> I am certain that HW items such as in-box 802.11g, FLAC decode and much
> larger buffer must be on the wishlist for the next design revision.
>

Don't forget that a larger buffer can create as many problems as it
solves. I for one wouldn't like any delay between hitting a button and
hearing a response.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

[ron thigpen]

Jack Coates wrote:

> Don't forget that a larger buffer can create as many problems as it
> solves. I for one wouldn't like any delay between hitting a button and
> hearing a response.

Don't forget that you don't strictly need to fill a buffer before you
begin consuming it's contents. If the bits can be delivered faster than
realtime playback requires, the fill can continue after playback begins.
Granted, you wouldn't get the benefit of deep buffering until some
small period into the track, but you'd gain a more responsive UI. All
of this may require more complex buffer management algorithms, but that
may be exactly what Sean has been hacking lately. We'll know when we know.

--rt

[ron thigpen]

Brian Abbott, ACA Systems wrote:
> I seem to recall that the 'official' position on streaming FLAC/WAV is that
> 'it might work if the connection is good, but if not you can always attach a
> 8011.g access point to the SP's rj45 ...'

I might paraphrase my memory of this as: "should the performance
implications, imagined or otherwise, of running a mixed 802.11b/g
network be unacceptable to you, the official position on how you might
get to a pure G wireless network is to attach an 802.11g access point to
the SB's RJ45. Depending on the cause, this may or may not improve the
playback issues you are experiencing with your SB."

I am certain that HW items such as in-box 802.11g, FLAC decode and much
larger buffer must be on the wishlist for the next design revision.

That's not to say we shouldn't improve the server in the meantime.

--rt

[Kevin Cramer]

But that is the theoretical maximum for the medium. The wired interface
can probably get very close, especially if you have a switch which
reduces the amount lost to sharing the network with other computers.

The wireless will never get that and it drops fast as you lose the
transmission strength. You are also sharing that and as far as I know
there is no way to get the benefits of a switch. Each client is taking
from the 11Mb/s pool.

I still find the wireless enough to stream FLAC though. I haven't tried
using the laptop (with a wireless connection) at the same time the
Squeezebox is playing. I keep wondering if it might be worth it to get
a cable out to the Squeezebox though. It would at least take the
wireless issue out of the equation.

Kevin

On Tue, 04 Jan 2005 17:50:54 +0000, "Robin Bowes"
<robin-lists-uu/***@public.gmane.org> said:
> I think it would be worth pointing out that the wired interface on the
> SB is only 10Base-T, i.e. 10Mb/s. Wireless 11b is theoretically 11Mb/s
> i.e. more than the wired port!

[Phillip Kerman]

I get short dropouts with the wired network (not talking about wireless).

Is this really the list of priorities?

"The main goals of the SlimServer project in the near term, in rough
priority order, are:
* Stability and performance - No crashers, quick startup, no skips,
less memory usage.


If so, I think this list should be revisited. They need to be addressed in
order or you'll constantly be chasing random issues. I realize that some
people don't experience the dropouts, but I think they're worse in more
recent builds.

Incidentally, I don't see a ton of people chiming in with random pet issues.
Rather, the sense I'm hearing (and it's not like there's a debate
here--we're all on the same side) is that the core features are important.

Thanks,
Phillip

[Anthony James]

On Tue, 4 Jan 2005 09:05:23 -0800, Phillip Kerman
<lists-o+I0KgJKNbax1f37qs3qIgC/***@public.gmane.org> wrote:
> I get short dropouts with the wired network (not talking about wireless).

I still havent worked out what's causing my dropouts. I'm using
Softsqueeze, a wired Squeezebox and a wireless one on Windows XP SP2.

Desipite ripping using EAC/Lame alt-preset-extreme to give VBR MP3s I
have files that will not play without silent patches or occaisionally
skipping to the next track. One album (Scissor Sisters) seemed to
give problems even after deleting from my server and re-ripping so
i've not really established whether its a file or server problem.
I've run some diagnostics on my hard disc without anything showing up.

I could do with some pointers on diagnosing the problem if anyone can
help - which logs to monitor on Slim would be a start.

Synchronisation between Softsqueeze and the hardware players is poor
and other apps interupt playback - watching a slideshow in Adobe
Photoshop Album caused softsqueeze to stall each time the image
changed. This is on a 3ghz P4 with a gig of RAM so system resources
should not be an issue.

[Michael Amster]

>
> In terms of the product itself, only a bigger buffer on the Squeezebox
> might help. I am getting what I consider to be my money's worth out of
> the product as it stands; should Slimdevices release a new version of
> the Squeezebox with additional features (bigger buffer; more native
> protocols; support for DRM; whatever), I'd buy one -- just as I'd
> consider buying a new iPod to replace the iPod Mini I'm currently
> enjoying (and getting my money's worth out of, despite all its
> limitations). But for now I realize there are certain limitations,
> none of which seem to be the end of the world to me, and only some of
> which are related to the product itself. (Though obviously other
> people's mileage will vary.)
>
> SBB
>
>
>
I agree with Steve on the HW progress. I think I checked the code and
it appears that there is a 130K buffer or there abouts on the Squeezebox
- if we grew that to double, it would support longer dropouts- I believe
it would cover my FLAC->PCM experience as well. I think that our
current issue is that FLAC users epecially are pushing the bit moving
infrastructure to the edge and there is not enough leaway on the server
bit pushing side or on the Squeezebox buffering side to make up for
802.11b glitches and server side overhead.

I think people "get it", but architecture always takes a back seat to
features in a customer driven app. I hope that the 6.0 branch gives the
developers the breathing room to get the DB infrastructure in place. I
think this will bandaid the server performance side for most, but they
should be strong about sticking to their guns on required architectural
improvements.

-MA

[kdf]

Quoting Michael Amster <mamster-***@public.gmane.org>:
> I think people "get it", but architecture always takes a back seat to
> features in a customer driven app. I hope that the 6.0 branch gives the
> developers the breathing room to get the DB infrastructure in place. I
> think this will bandaid the server performance side for most, but they
> should be strong about sticking to their guns on required architectural
> improvements.

I can't speak for everyone, but I certainly feel no time pressure in regard to
6.0. That would indicate plenty of breathing room from my perspective. As far
as being strong: this would be why I am not really taking part in the threading
discussions. Right now, its about the DB. Threading is desired and planned as
a performance enhancer. The DB comes first, with the code being written in
such a way as to open the door to breaking things up into threads. In fact,
one of Dan's changes yesterday will allow a separate copy of SlimServer to run
as a scanner only.

-kdf

[Kevin Cramer]

I've been watching this thread and I've wondered if anyone has
considered just using a separate process to stream the audio to the
player. That might be easier to implement for now as the threading
could be problematic as others have pointed out. It's only job would be
to stream the audio and to listen for requests to pause, play, etc.

I was also wondering what percentage of people experiencing dropouts are
using the wireless as opposed to wired. I have a Buffalo Linkstation
now (used to use a Mac OS X desktop) and I only occasionaly get
dropouts/server restarts over my 802.11b (an Airport bridges my wired
and wireless). I'm also using 128 bit WEP. I'm streating FLAC most of
the time. I do think there is an issue but it seems that many others
are having more problems than I am. I haven't spent the time to dig
into what causes my problems. I'll also admit that I don't do anything
on the server while I'm playing as I've seen that it can cause problems,
especially on the Linkstation.

Kevin

On Tue, 04 Jan 2005 10:48:52 -0800, "kdf" <slim-mail-DZohY95GSGB31fZj3l7iyQC/***@public.gmane.org>
said:
> In fact, one of Dan's changes yesterday will allow a separate copy of
> SlimServer to run as a scanner only.
>
> -kdf

[Steve]

discuss-bounces-***@public.gmane.org wrote:
> kdf wrote:
> ...
>
>> The frank reality is that the dropouts are known, and may or may not
>> be solved by the db. they are not, however, the goal of the db.
>> Many people, including myself have no problems with dropouts. I
>> expect the ultimate solution for that is a more robust reporting
>> structure for streaming performance so that network issues can be
>> better detected and resolved. Heck, for all I know 802.11 may just
>> not be solid enough to guarantee what it claims in all cases.
>
> This is my opinion as well. 802.11b as a protocol and from a gear
> quality perspective is just not there for streaming. It's
> great when it
> works, but the factors that can make it not work are legion.
>
I have tried to keep out of this, but I just want to make it clear, that the
dropout problem is NOT an 802.11 problem, or at least not solely an 802.11
problem. I and others suffer from dropouts with a wired network. It least
some of the dropouts seem to be related to library scans, but then others
happen at random times. So, those problems might well be reduced by the db.

-Steve

[Robin Bowes]

Steve wrote:
>
> I have tried to keep out of this, but I just want to make it clear, that the
> dropout problem is NOT an 802.11 problem, or at least not solely an 802.11
> problem. I and others suffer from dropouts with a wired network. It least
> some of the dropouts seem to be related to library scans, but then others
> happen at random times. So, those problems might well be reduced by the db.

Steve,

I use a wireless SB, but I'm pretty sure that all the dropouts I get are
caused by a busy slimserver process rather than network issues. My SB is
only approx 6ft from my access point (through a wall) and I get 88%
signal strength. I'm pretty sure that's not causing any problems. If it
were the network losing connection then I would see the "lost connection
" message, but I don't - I just get a drop out.

R.

PS. Surefire way to cause a dropout: Click on the Statistics link in the
web interface window - my playback lasts about 1.5 seconds then goes
away until the statistics page is displayed. Incidentally, this cause a
"lost connection" message on my Squeezebox. Also, it causes the
slimserver process to use as much CPU as it can get, i.e. around 97%.

[Steve Baumgarten]

> PS. Surefire way to cause a dropout: Click on the Statistics link in the
> web interface window - my playback lasts about 1.5 seconds then goes
> away until the statistics page is displayed. Incidentally, this cause a
> "lost connection" message on my Squeezebox. Also, it causes the
> slimserver process to use as much CPU as it can get, i.e. around 97%.

People should be careful to distinguish the different kinds of dropouts.
There are server-related dropouts -- these are well known. Search for a
song, do pretty much anything that's CPU intensive, and you get a "lost
connection" message. This kind of dropout should be taken care of by the
6.0 work -- it's a direct result of the inefficient memory-based storage
and access methods currently used by the server.

The other kind of dropout is the kind you get sometimes when the server
is doing nothing at all other than streaming music (and your PC is also
not loaded down with other applications). No load on the PC; the server
doing nothing but streaming to the Squeezebox -- and yet sometimes the
music stops playing for a few seconds. This type of dropout tends to be
seen by people on wireless connections and is almost always caused by a
wireless glitch.

To the people seeing dropouts on wired connections: do you see these
when the server is simply streaming music (i.e., not being asked to do
anything, even refresh a web page) and the CPU is not loaded? Because if
so, then something is really pretty wrong somewhere.

(Turn off the rescan interval, if it's on. And there's also a mod to
disable the period cache flush to disk. With these things disabled, the
server will become completely dedicated to playing a stream of music and
responding to IR commands from the remote -- it won't suddenly decide,
oh, I have to do some disk intensive stuff to do now and get involved
long enough for the stream to stop. Under these circumstances I'd be
surprised to hear that dropouts still occur on a wired connection.)

SBB




Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.

[Phillip Kerman]

> To the people seeing dropouts on wired connections: do you see these
> when the server is simply streaming music (i.e., not being
> asked to do
> anything, even refresh a web page) and the CPU is not loaded?
> Because if
> so, then something is really pretty wrong somewhere.


Yeah, I'll turn off all apps on my computer and I still get it.

>
> (Turn off the rescan interval, if it's on. And there's also a mod to
> disable the period cache flush to disk. With these things
> disabled, the
> server will become completely dedicated to playing a stream
> of music and
> responding to IR commands from the remote -- it won't
> suddenly decide,
> oh, I have to do some disk intensive stuff to do now and get involved
> long enough for the stream to stop. Under these circumstances I'd be
> surprised to hear that dropouts still occur on a wired connection.)

Where is the rescan interval?

Also, where is "disable the period cache flush to disk" set?

What about "Build Items Per Pass" What should I set that to?


Thanks,
Phillip

[Jason Holtzapple]

Phillip Kerman wrote:
>>(Turn off the rescan interval, if it's on. And there's also a mod to
>>disable the period cache flush to disk. With these things
>>disabled, the
>>server will become completely dedicated to playing a stream
>>of music and
>>responding to IR commands from the remote -- it won't
>>suddenly decide,
>>oh, I have to do some disk intensive stuff to do now and get involved
>>long enough for the stream to stop. Under these circumstances I'd be
>>surprised to hear that dropouts still occur on a wired connection.)
>
>
> Where is the rescan interval?

Server Settings:Plugins

> Also, where is "disable the period cache flush to disk" set?

You can't set it without a source code distribution of slimserver.
It is in line 90 of Music/Info.pm

> What about "Build Items Per Pass" What should I set that to?

I believe the default is ok (5?). It shouldn't affect performance
unless your library is being actively rescanned.

[kdf]

Quoting Jason Holtzapple <jasonholtzapple-/***@public.gmane.org>:


> > Where is the rescan interval?
>
> Server Settings:Plugins

By default, that is off. There is also a rescan interval in server
settings->itunes, server settings->musicmagic, and server settings->moodlogic
if you happen to be using any of those.

> > What about "Build Items Per Pass" What should I set that to?
>
> I believe the default is ok (5?). It shouldn't affect performance
> unless your library is being actively rescanned.

5 is the current default. Older installs used 100, so that might have carried
over. There is a visible and audible improvement going from 100 to 5 on
certain systems.
-kdf

[Steve]

Steve Baumgarten wrote:
> To the people seeing dropouts on wired connections: do you see these
> when the server is simply streaming music (i.e., not being
> asked to do
> anything, even refresh a web page) and the CPU is not loaded? Because
> if so, then something is really pretty wrong somewhere.

I have a dedicated server which only runs slimserver. Well, sometimes I have
Laplink running so I don't have to keep running downstairs. It is a WinXP
system with a 1.4Mhz processor and 512MB of ram. My library currently has
17,330 songs in it. The problem is most apparent when playing FLAC or Apple
Lossless files. Of course, in these cases, there are additional processes
running (Quicktime or LAME). However, it will happen with mp3s
occassionally.
>
> (Turn off the rescan interval, if it's on. And there's also a mod to
> disable the period cache flush to disk. With these things
> disabled, the
> server will become completely dedicated to playing a stream
> of music and
> responding to IR commands from the remote -- it won't
> suddenly decide,
> oh, I have to do some disk intensive stuff to do now and get involved
> long enough for the stream to stop. Under these circumstances I'd be
> surprised to hear that dropouts still occur on a wired connection.)

Ah, but they do. There is definitely a reproducable dropout when library
scanning occurs. But, sometimes it just happens at irregular intervals
independent of the rescans. I have made the rescan interval arbitrarily
large (several days), but I still have periodic unpredictable dropouts in
the sound which last for just a few seconds. In fact, none of my dropouts
last more than a second or two, even if a scan is in progress.

-Steve

[Michael Haan]

_______________________________________________
Discuss mailing list
Discuss-***@public.gmane.org
http://lists.slimdevices.com/lists/listinfo/discuss

[Jason]

We (the company I work for) regularly stream very high quality G711 encoded
voice over IP audio over wireless networks and don't have trouble. The real
challenge/opportunity is in building a very reliable RTCP based statusing
system into the delivery processes so that you can know exactly when you are
receiving network issues and correlate them to audio dropouts, etc.

> -----Original Message-----
> From: discuss-bounces-***@public.gmane.org
> [mailto:discuss-bounces-***@public.gmane.org] On Behalf Of
> Jack Coates
> Sent: Tuesday, January 04, 2005 8:43 AM
> To: Slim Devices Discussion
> Subject: Re: [slim] quick summary of 6.0 changes?
>
> kdf wrote:
> ...
>
> > The frank reality is that the dropouts are known, and may
> or may not
> > be solved by the db. they are not, however, the goal of
> the db. Many
> > people, including myself have no problems with dropouts. I
> expect the
> > ultimate solution for that is a more robust reporting structure for
> > streaming performance so that network issues can be better detected
> > and resolved. Heck, for all I know 802.11 may just not be
> solid enough to guarantee what it claims in all cases.
>
> This is my opinion as well. 802.11b as a protocol and from a
> gear quality perspective is just not there for streaming.
> It's great when it works, but the factors that can make it
> not work are legion.
>
> Open question, maybe a write up on how to use SoftSqueeze to
> pre-check a site's wireless streaming capabilities is in order?
>
> --
> Jack at Monkeynoodle dot Org: It's a Scientific Venture...
> Riding the Emergency Third Rail Power Trip since 1996!
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss
>

[Dan Goodinson]

Personally speaking, I'm happy with the current features. Any new
features would, of course, be a plus. But one thing that takes the edge
off my squeezebox is the random reboots. In terms of features, I would
be pretty happy if the current feature set NEVER changed - it's great
already. But the most important thing for me is to enjoy the music -
which I sometimes find difficult when SB reboots every once in a while
(e.g. at least once per day when I use it, frequently more often). I
experienced pretty serious reboots from day 1. I find myself kind of
cautious about recommending it at the moment, since it's proven to be
pretty unstable (although certainly getting gradually better).

I don't want to rant (apologies if this is taken as such) but to me, the
most important feature of SB is the ability to stream music to my
stereo. This is the only real feature that matters to me. This is what
it's designed to do as far as I understand.

To me it's like having a car that you can drive most of the time but it
occasionally dies when you're going somewhere. And while several
customers experience this, the primary focus is not on fixing the
engine, but making the fuel economy better. Sure the MPG would be nice,
but not much use when you can't drive for more than a couple of hours
before having to restart the engine. I'd rather be able to drive the
thing reliably first, before I start getting concerned about how much
fuel I put in it. (I'm only using this as an analogy - please don't
flame me by throwing the analogy back at me with talk of the
environment, and the world oil resources or whatever ;-)

I guess it depends on how many users have actually reported a problem
with reboots. If it's only 1% of the customer base, then I can
understand that this is probably low priority :-(

My 2p.

-----Original Message-----
From: discuss-bounces-***@public.gmane.org
[mailto:discuss-bounces-***@public.gmane.org] On Behalf Of Phillip
Kerman
Sent: 04 January 2005 17:05
To: 'Slim Devices Discussion'
Subject: RE: [slim] quick summary of 6.0 changes?


I get short dropouts with the wired network (not talking about
wireless).

Is this really the list of priorities?

"The main goals of the SlimServer project in the near term, in rough
priority order, are:
* Stability and performance - No crashers, quick startup, no skips,
less memory usage.


If so, I think this list should be revisited. They need to be addressed
in order or you'll constantly be chasing random issues. I realize that
some people don't experience the dropouts, but I think they're worse in
more recent builds.

Incidentally, I don't see a ton of people chiming in with random pet
issues. Rather, the sense I'm hearing (and it's not like there's a
debate here--we're all on the same side) is that the core features are
important.

Thanks,
Phillip

[Jack Coates]

Dan Goodinson wrote:
> Personally speaking, I'm happy with the current features. Any new
> features would, of course, be a plus. But one thing that takes the edge
> off my squeezebox is the random reboots. In terms of features, I would
> be pretty happy if the current feature set NEVER changed - it's great
> already. But the most important thing for me is to enjoy the music -
> which I sometimes find difficult when SB reboots every once in a while
> (e.g. at least once per day when I use it, frequently more often). I
> experienced pretty serious reboots from day 1. I find myself kind of
> cautious about recommending it at the moment, since it's proven to be
> pretty unstable (although certainly getting gradually better).
>
> I don't want to rant (apologies if this is taken as such) but to me, the
> most important feature of SB is the ability to stream music to my
> stereo. This is the only real feature that matters to me. This is what
> it's designed to do as far as I understand.
>
> To me it's like having a car that you can drive most of the time but it
> occasionally dies when you're going somewhere. And while several
> customers experience this, the primary focus is not on fixing the
> engine, but making the fuel economy better. Sure the MPG would be nice,
> but not much use when you can't drive for more than a couple of hours
> before having to restart the engine. I'd rather be able to drive the
> thing reliably first, before I start getting concerned about how much
> fuel I put in it. (I'm only using this as an analogy - please don't
> flame me by throwing the analogy back at me with talk of the
> environment, and the world oil resources or whatever ;-)
>

To extend the analogy, what's making the car die? Maybe it's related to
the fuel economy issue that's being worked on.

SQL backend will reduce memory and CPU consumption, which will have
far-reaching effects. Plugins and new features able to use that SQL
backend will bring memory and CPU consumption back up, prompting the
next big revision (I'd expect 6.5 or 7.0 to use multiple processes or
threads, one way or the other).

I've just looked up your problem and it looks suspicious to me -- I'm
thinking that there's something evil about your USR access point. You
might be able to figure out what by watching it with Ethereal, but then
you've got to fight with 3Com about fixing it. I'd try picking up an el
cheapo 802.11b AP on ebay or a couple of powerline adapters, personally.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

[Daniel Cohen]

On 4/1/05 at 5:22 pm +0000, Dan Goodinson wrote
>Personally speaking, I'm happy with the current features. Any new
>features would, of course, be a plus. But one thing that takes the edge
>off my squeezebox is the random reboots. In terms of features, I would
>be pretty happy if the current feature set NEVER changed - it's great
>already. But the most important thing for me is to enjoy the music -
>which I sometimes find difficult when SB reboots every once in a while
>(e.g. at least once per day when I use it, frequently more often). I
>experienced pretty serious reboots from day 1. I find myself kind of
>cautious about recommending it at the moment, since it's proven to be
>pretty unstable (although certainly getting gradually better).
>
>
>I guess it depends on how many users have actually reported a problem
>with reboots. If it's only 1% of the customer base, then I can
>understand that this is probably low priority :-(

I think the difficulty is not the numbers of people who have
problems, but the fact that systems are so variable (machine, OS,
network quality, etc.) that it's hard to diagnose or even to debug.

Just as one example, with the way I currently use the Squeezebox
(primarily for mp3 s made from radio programmes) the only dropouts I
have come from use of the microwave. The Squeezebox usually loses
contact with the server when my computer has been asleep for a long
time, but only then. This was a hassle with one of the old versions
of the firmware as I often had to disconnect the power and reconnect
to get it working. Nowadays, though, when I have this problem I just
hold the power key down until the display says "Restarting ..." and
it then goes through a process at the end of which it has recovered.

Maybe I've just been lucky.
--
Daniel Cohen

[Graham Ridgway at home]

As a relatively low user of functionality (7,000 mp3s which I browse, search
and play), I have a very simple 'users' perspective on the whole development
thing. The slim system just has to work and work really well. When I first
started with my first 3 slimp3s some while ago, the whole setup was
brilliant. It came out the box and was fabulous. It was a fast and
reliable "sound system". I added 2 more slimp3's and then 2 SBs and I am
now on server 5.3.1.

Now it works mostly, is okish, but I regard it as a computer system, not a
sound system. It needs maintenance, stuff goes wrong, slimps need power
cycling, sometimes the server crashes and I have double entries that have to
be deleted, my kids call me at work as they need "slim support". A lot of
discussion here is about a piece of software, release priorities,
reliability versus new features, talk of software development, not of a home
appliance.

So it comes down to marketing, not software. Namely, who are the future
buyers? What are they buying...a software system that's a bit cranky like
the computer they use at home or work? Or is it a music system like the CD
player, TV etc at home. I don't know the answer to that question as it's
not mine to answer.

With 7 slims, I like my system (where I used to love it), some of the time
it's a real PITA to keep running. Am I anything like the target market?
Dunno. But I bought a telly with integrated DVD at xmas. That was pretty
hard to switch from TV to DVD and back. It was just like my slim system
sometimes is! I took it straight back to the shop.

I'm not saying that's what I want to do with my slim system as I still like
it and the functionality I use. But I go back to what I am looking for and
that's...it works brilliantly like my Hifi and my telly.

Just some (dumb) user feedback.

Graham

[Daniel Cohen]

On 4/1/05 at 10:25 pm +0000, Graham Ridgway at home wrote
>As a relatively low user of functionality (7,000 mp3s which I
>browse, search and play), I have a very simple 'users' perspective
>on the whole development thing. The slim system just has to work
>and work really well. When I first started with my first 3 slimp3s
>some while ago, the whole setup was brilliant. It came out the box
>and was fabulous. It was a fast and reliable "sound system". I
>added 2 more slimp3's and then 2 SBs and I am now on server 5.3.1.
>
>Now it works mostly, is okish, but I regard it as a computer system,
>not a sound system. It needs maintenance, stuff goes wrong, slimps
>need power cycling, sometimes the server crashes and I have double
>entries that have to be deleted, my kids call me at work as they
>need "slim support".

Are you really using all seven units at once? Or is it a matter of
just having a couple on at once, but different ones at different
times?

If the first, I'm not surprised you have problems. I don't believe a
wireless system can cope with that many units.

I reckon that a straightforward "sound system" would not run more
than two Squeezeboxes.

If one looks at audiophile multi-room systems, they are extremely
expensive and are wired units. Fitting more wiring is the main reason
I haven't bought such a system.
--
Daniel Cohen

[Michael Herger]

[..]
> I reckon that a straightforward "sound system" would not run more than
> two Squeezeboxes.

Well, I do three at a time with no problem at all (2 SB wireless, 1 SliMP3
on a wireless bridge). But this is an old house with little ferroconcrete.
Only old journals as isolation - has its advantages, too ;-)

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

[Daniel Cohen]

On 5/1/05 at 9:53 am +0100, Michael Herger wrote
>[..]
>>I reckon that a straightforward "sound system" would not run more
>>than two Squeezeboxes.
>
>Well, I do three at a time with no problem at all (2 SB wireless, 1
>SliMP3 on a wireless bridge). But this is an old house with little
>ferroconcrete.

Yes, I didn't mean that the hardware/software was limited to two.
Rather that if we are considering what an "average user" would want,
and would expect to work out of the box, then having two players is
all they would require.
--
Daniel Cohen

[Anthony James]

On Wed, 5 Jan 2005 09:52:57 +0000, Daniel Cohen <danco-***@public.gmane.org> wrote:
> Yes, I didn't mean that the hardware/software was limited to two.
> Rather that if we are considering what an "average user" would want,
> and would expect to work out of the box, then having two players is
> all they would require.

I'm not sure about that at all. Whilst it might take some time to buy
I think there are a lot of users who would want Living Room, Kitchen,
Bedroom and at their PC (though the last might be a software player).
That's four players for a start.

[Jules Taplin]

Well... of the 5 SB's in my place... 3 of them are wireless.


-- Jules

Michael Herger wrote:

> [..]
>
>> I reckon that a straightforward "sound system" would not run more
>> than two Squeezeboxes.
>
>
> Well, I do three at a time with no problem at all (2 SB wireless, 1
> SliMP3 on a wireless bridge). But this is an old house with little
> ferroconcrete. Only old journals as isolation - has its advantages,
> too ;-)
>

[Anthony James]

On Wed, 05 Jan 2005 19:20:45 +0000, Jules Taplin
<slim-discuss-e9k7pQ7bHK+tmTQ+***@public.gmane.org> wrote:
> Well... of the 5 SB's in my place... 3 of them are wireless.

and this evening my Wireless Squeezebox gave the worst performance
ever. An album that played perfectly a few days ago, on the same
wireless player, was repeatedly pausing/going silent despite the
buffer never showing less than 99%.

[Graham Ridgway at home]

It's pretty rare that all 7 go at once, normally max at 3. It's wired not
wireless (well 1 slimp3 runs on a wireless bridge and only normally stops
when the microwave is going). I actually don't experience what I would call
concurrency probs. Just there's a lot of faffing. It has changed from a
music system to s computer system. Now I can't tell whether that has
changed over time because the number of units has or because the slim system
(hw and sw) has.

I actually have quite a lot of the core cabling and back-boxes for a Linn
multi-room system, but went slimp3 because of the simplicity, but mainly
cost.

Graham
----- Original Message -----
From: "Daniel Cohen" <danco-***@public.gmane.org>
To: "Slim Devices Discussion" <discuss-***@public.gmane.org>
Sent: Tuesday, January 04, 2005 11:20 PM
Subject: Re: [slim] A user's perspective



> Are you really using all seven units at once? Or is it a matter of just
> having a couple on at once, but different ones at different times?
>
> If the first, I'm not surprised you have problems. I don't believe a
> wireless system can cope with that many units.
>
> I reckon that a straightforward "sound system" would not run more than two
> Squeezeboxes.
>
> If one looks at audiophile multi-room systems, they are extremely
> expensive and are wired units. Fitting more wiring is the main reason I
> haven't bought such a system.
> --
> Daniel Cohen
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss
>

[I***@public.gmane.org]

I too feel like Graham, only my problem is a bit more deep rooted. I bought
a SB which I managed to get up and running in a relatively short period of
time, and loved it. I used it for about 9 months with no problems to speak of.
Unfortunately I had to reboot my computer (From scratch, with a full system
reload), and lo and behold I now cannot use my SB>

I have tried everything I can think of. I have followed advice from others
in the forum,(the reason I joined), but still the same old message "Cannot find
slimserver.check software is running!

I am in no way a computer expert, nor have any programming knowledge. Why
should I? Isnt this after all a consumer item. No one says "buy it its
brilliant...............but only if you are a computer scientist!"

There are no instructions about connecting to a wireless network. Going into
firewall and opening ports! Setting up manual IP addresses! Pinging the SB!

Like Graham.......why cant I just open the box, plug in the SB and it works?

You guys are all talking about using it display this, run
that.............can i just get mine to do what it is supposed to do? ie Play my tunes! I
read in the forum recently, that a guy in Sweden ordered SB, got it delivered
in 3 days, and couldn't get it to connect either There cant be many "Consumer"
products around that you cant use yet the manufacturer can wash their hands
and say "Its down to you!"

Where are the instructions (In common English please), that tell you how to
fix this problem?

My SB connects to my Wireless network in 2 seconds, but cant find the
software to run it.

Sorry for the rant, but I am so P####D off.

HEEEEEEEEEEEELLLLLLLLLLLLLLLLPPPP!

[Robin Bowes]

IainHar-***@public.gmane.org wrote:
> I too feel like Graham, only my problem is a bit more deep rooted. I
> bought a SB which I managed to get up and running in a relatively short
> period of time, and loved it. I used it for about 9 months with no
> problems to speak of. Unfortunately I had to reboot my computer (From
> scratch, with a full system reload), and lo and behold I now cannot use
> my SB>
>
> I have tried everything I can think of. I have followed advice from
> others in the forum,(the reason I joined), but still the same old
> message "Cannot find slimserver.check software is running!
>
> I am in no way a computer expert, nor have any programming knowledge.
> Why should I? Isnt this after all a consumer item. No one says "buy it
> its brilliant...............but only if you are a computer scientist!"
>
> There are no instructions about connecting to a wireless network. Going
> into firewall and opening ports! Setting up manual IP addresses! Pinging
> the SB!
>
> Like Graham.......why cant I just open the box, plug in the SB and it works?
>
> You guys are all talking about using it display this, run
> that.............can i just get mine to do what it is supposed to do? ie
> Play my tunes! I read in the forum recently, that a guy in Sweden
> ordered SB, got it delivered in 3 days, and couldn't get it to connect
> either There cant be many "Consumer" products around that you cant use
> yet the manufacturer can wash their hands and say "Its down to you!"
>
> Where are the instructions (In common English please), that tell you how
> to fix this problem?
>
> My SB connects to my Wireless network in 2 seconds, but cant find the
> software to run it.
>
> Sorry for the rant, but I am so P####D off.
>
> HEEEEEEEEEEEELLLLLLLLLLLLLLLLPPPP!

Iain (I'm guessing your name from the mangle gmane email address!),

Can you give us a few more details about your setup? For example:

On what O/S are you running slimserver?
What is your network topology, i.e. how is the Squeezebox connected to
the network? How is the "server" connected to the network?

Try to remain calm and a little more analytical. For example, what is
different between your new installation (which works) and the old one
(which doesn't)?

A wild stab in the dark - are you now running WinXP Service Pack 2? If
so, I'll put money on this being a firewall issue. If that's all it is
then it's trivial to fix.

R.

[Jack Coates]

IainHar-***@public.gmane.org wrote:
...
> You guys are all talking about using it display this, run
> that.............can i just get mine to do what it is supposed to do? ie
> Play my tunes! I read in the forum recently, that a guy in Sweden
> ordered SB, got it delivered in 3 days, and couldn't get it to connect
> either There cant be many "Consumer" products around that you cant use
> yet the manufacturer can wash their hands and say "Its down to you!"
>

Is that what Support said? I find it unlikely. Perhaps you should try
contacting support-SBQ2+***@public.gmane.org

> Where are the instructions (In common English please), that tell you how
> to fix this problem?
>
> My SB connects to my Wireless network in 2 seconds, but cant find the
> software to run it.
>
> Sorry for the rant, but I am so P####D off.
>
> HEEEEEEEEEEEELLLLLLLLLLLLLLLLPPPP!
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss


--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

[Jason]

Well, unfortunately consumer network devices that you "simply plug in and
they work" don't exist per se. Remember that there are hundreds of
manufacturers of network equipment and thousands of models of access points,
network switches, etc, and no way for Slim to test every single combination
that exists.

Have you even tried contacting Slim technical support to help you in
troubleshooting the problem? They hardly say "it's on you" when you have a
problem. The worst thing that might happen is that you have to return the
product for a refund.

I would recommend that since you hint at your product being connected
wirelessly you try direct connecting the Squeezebox to your PC/server with
an ethernet crossover cable and give both devices static addresses such as
192.168.0.1 for the PC and 192.168.0.2 for the Squeezebox. If everything
then works wonderfully then the problem is likely in your network.


_____

From: discuss-bounces-***@public.gmane.org
[mailto:discuss-bounces-***@public.gmane.org] On Behalf Of IainHar-***@public.gmane.org
Sent: Tuesday, January 04, 2005 3:48 PM
To: discuss-***@public.gmane.org
Subject: Re: [slim] A user's perspective



I too feel like Graham, only my problem is a bit more deep rooted. I bought
a SB which I managed to get up and running in a relatively short period of
time, and loved it. I used it for about 9 months with no problems to speak
of. Unfortunately I had to reboot my computer (From scratch, with a full
system reload), and lo and behold I now cannot use my SB>

I have tried everything I can think of. I have followed advice from others
in the forum,(the reason I joined), but still the same old message "Cannot
find slimserver.check software is running!

I am in no way a computer expert, nor have any programming knowledge. Why
should I? Isnt this after all a consumer item. No one says "buy it its
brilliant...............but only if you are a computer scientist!"

There are no instructions about connecting to a wireless network. Going into
firewall and opening ports! Setting up manual IP addresses! Pinging the SB!

Like Graham.......why cant I just open the box, plug in the SB and it works?

You guys are all talking about using it display this, run
that.............can i just get mine to do what it is supposed to do? ie
Play my tunes! I read in the forum recently, that a guy in Sweden ordered
SB, got it delivered in 3 days, and couldn't get it to connect either There
cant be many "Consumer" products around that you cant use yet the
manufacturer can wash their hands and say "Its down to you!"

Where are the instructions (In common English please), that tell you how to
fix this problem?

My SB connects to my Wireless network in 2 seconds, but cant find the
software to run it.

Sorry for the rant, but I am so P####D off.

HEEEEEEEEEEEELLLLLLLLLLLLLLLLPPPP!

[Dan Goodinson]

The microwave is a sure-fire way to cause SB to crash and reboot. We
always kind of knew this, but we proved it fairly early on in our house.
The crash was really that - a crash. SB fully shut-down and rebooted.
The symptoms kind of suggest that the other reboots may be related to
some sort of interference, and so we've changed channels a number of
times to try and avoid it. Currently running on ch13, since this is at
the top end of the scale and doesn't get hit so badly by microwaves or
phones.

End of the day though, all other wireless devices in the house aren't
affected anything like as bad. If the problem truly is purely
interference, then nothing else in the house is affected now - just SB.

As for USR, yes - this is definitely a possibility. Although in general
when I make router changes (which require a restart of the router), SB
simply loses connection for a short while and then reconnects when the
network is back. I'd consider this a "graceful" restart. (Not even a
"restart", in fact). The thing that concerns me is the complete crash
and restart (e.g. display goes dark, then I get the "slim" splash
screen, then it cycles through the connection process) - this definitely
isn't "graceful" and indicates a serious issue (either a burst of
interference, possibly a hardware issue, or something else as yet
unidentified). I like the idea of using ethereal to capture what is
going on - I'm going to get onto that when I get home ;)

I was chatting to another guy on this list who uses same USR hardware as
me and doesn't see any dropouts at all plus a further guy who
experienced same problem who WASN'T using USR, so it's certainly not a
USR-specific issue. When I talk about the stability issues, this is
what I mean.

But maybe this should belong on a different thread ;) Sorry for the
hi-jack :) Back on topic......

-----Original Message-----
From: discuss-bounces-***@public.gmane.org
[mailto:discuss-bounces-***@public.gmane.org] On Behalf Of Daniel Cohen
Sent: 04 January 2005 17:39
To: Slim Devices Discussion
Subject: RE: [slim] quick summary of 6.0 changes?

>I guess it depends on how many users have actually reported a problem
>with reboots. If it's only 1% of the customer base, then I can
>understand that this is probably low priority :-(

I think the difficulty is not the numbers of people who have
problems, but the fact that systems are so variable (machine, OS,
network quality, etc.) that it's hard to diagnose or even to debug.

Just as one example, with the way I currently use the Squeezebox
(primarily for mp3 s made from radio programmes) the only dropouts I
have come from use of the microwave. The Squeezebox usually loses
contact with the server when my computer has been asleep for a long
time, but only then. This was a hassle with one of the old versions
of the firmware as I often had to disconnect the power and reconnect
to get it working. Nowadays, though, when I have this problem I just
hold the power key down until the display says "Restarting ..." and
it then goes through a process at the end of which it has recovered.

Maybe I've just been lucky.
--
Daniel Cohen

[Bart Maguire]

I have been about to give up on my Squeezebox several times. It is
not easy to set up or use and the documentation and help is not easy
to find and is incomplete.
In particular I am practically unable to make a playlist, the interface via
the remote is far too slow and the web interface is also far too slow
and requires the mouse. I don't use a mouse. For our New Years Day
party I gave up - I went back to my old Winamp system, made a 10
hour playlist in about 5 minutes and played it all day with no
intervention, no lockups and no dropouts. My Winamp system has
been totally reliable for years, has a VFD display in my living room (the
PC is in the basement) and can be controlled with the mouse or a
remote control.
I only tried a Squeezebox because I thought it was being more actively
developed than Winamp, was open-source and might include better
management of streaming content.
Maybe I was wrong - wait to see if my Squeezebox appears on eBay in
a few weeks.

[Sally Shears]

Bart --

I won't join a give-and-take here since I don't think this is the
place. SqueezeBox may not be for everyone, but many of us are quite
happy. Sorry to hear it's not working well for you.

FWIW, I create my playlists in iTunes and let SlimServer use them.
The web interface works well for me as well even though my SlimServer
is on an ancient machine.

-- Sally

On Wed, 05 Jan 2005 17:25:11 -0000, Bart Maguire
<bartmaguire-/E1597aS9LT10XsdtD+***@public.gmane.org> wrote:
> In particular I am practically unable to make a playlist, the interface via
> the remote is far too slow and the web interface is also far too slow
> and requires the mouse. I don't use a mouse. For our New Years Day
> party I gave up - I went back to my old Winamp system, made a 10
> hour playlist in about 5 minutes and played it all day with no
> intervention, no lockups and no dropouts. ears on eBay in
> a few weeks.
--
Sally Shears (a.k.a. "Molly")
SallyShears-***@public.gmane.org -or- Sally-UBtzPAnmfa4dnm+***@public.gmane.org
(was sshears-En8VLACA011Wk0Htik3J/***@public.gmane.org)

[JC]

There are a lot of other devices on the market that do similar things. I chose
SB because of the open source software and how the support goes for it, which is
generally way, way way better then I'd EVER get if I shelled out for a "big
company" device and all I gotta do is join this list.

as a software engineer working on linux for many yrs, this was "home" for me.

but, for others, the whole linux thing is Greek Speak.



Sally Shears wrote:

> Bart --
>
> I won't join a give-and-take here since I don't think this is the
> place. SqueezeBox may not be for everyone, but many of us are quite
> happy. Sorry to hear it's not working well for you.
>
> FWIW, I create my playlists in iTunes and let SlimServer use them.
> The web interface works well for me as well even though my SlimServer
> is on an ancient machine.
>
> -- Sally
>
> On Wed, 05 Jan 2005 17:25:11 -0000, Bart Maguire
> <bartmaguire-/E1597aS9LT10XsdtD+***@public.gmane.org> wrote:
> > In particular I am practically unable to make a playlist, the interface via
> > the remote is far too slow and the web interface is also far too slow
> > and requires the mouse. I don't use a mouse. For our New Years Day
> > party I gave up - I went back to my old Winamp system, made a 10
> > hour playlist in about 5 minutes and played it all day with no
> > intervention, no lockups and no dropouts. ears on eBay in
> > a few weeks.
> --
> Sally Shears (a.k.a. "Molly")
> SallyShears-***@public.gmane.org -or- Sally-UBtzPAnmfa4dnm+***@public.gmane.org
> (was sshears-En8VLACA011Wk0Htik3J/***@public.gmane.org)
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss

[Graham Ridgway at home]

I guess that was one of my main points in starting the thread.

1. for me the experience is good, but not great like it used to be (and I
don't get drop-outs).
2. I assume that the clever people at slim devices (and I do mean that, it's
very hard not to sound sarcastic over email) are doing their stuff from a
market/marketing perspective. They have chosen their target audience. To
me (as a user) the whole opensource/linux thing is a complete red-herring
(good to see that publication back by the way). Although I would like to
think I'm really into funky features, plugins and the latest bits, I'm not!
I just want my music, easily playable round the house (and in my car),
sounding good and easily accessed by me and my family.

Graham
----- Original Message -----
From: "JC" <sb-***@public.gmane.org>
To: "Slim Devices Discussion" <discuss-***@public.gmane.org>
Sent: Friday, January 07, 2005 5:07 AM
Subject: Re: [slim] A user's perspective


>
> There are a lot of other devices on the market that do similar things. I
> chose
> SB because of the open source software and how the support goes for it,
> which is
> generally way, way way better then I'd EVER get if I shelled out for a
> "big
> company" device and all I gotta do is join this list.
>
> as a software engineer working on linux for many yrs, this was "home" for
> me.
>
> but, for others, the whole linux thing is Greek Speak.
>
>
>
> Sally Shears wrote:
>
>> Bart --
>>
>> I won't join a give-and-take here since I don't think this is the
>> place. SqueezeBox may not be for everyone, but many of us are quite
>> happy. Sorry to hear it's not working well for you.
>>
>> FWIW, I create my playlists in iTunes and let SlimServer use them.
>> The web interface works well for me as well even though my SlimServer
>> is on an ancient machine.
>>
>> -- Sally
>>
>> On Wed, 05 Jan 2005 17:25:11 -0000, Bart Maguire
>> <bartmaguire-/E1597aS9LT10XsdtD+***@public.gmane.org> wrote:
>> > In particular I am practically unable to make a playlist, the interface
>> > via
>> > the remote is far too slow and the web interface is also far too slow
>> > and requires the mouse. I don't use a mouse. For our New Years Day
>> > party I gave up - I went back to my old Winamp system, made a 10
>> > hour playlist in about 5 minutes and played it all day with no
>> > intervention, no lockups and no dropouts. ears on eBay in
>> > a few weeks.
>> --
>> Sally Shears (a.k.a. "Molly")
>> SallyShears-***@public.gmane.org -or- Sally-UBtzPAnmfa4dnm+***@public.gmane.org
>> (was sshears-En8VLACA011Wk0Htik3J/***@public.gmane.org)
>> _______________________________________________
>> Discuss mailing list
>> Discuss-***@public.gmane.org
>> http://lists.slimdevices.com/lists/listinfo/discuss
>
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss
>

[Jason]

I think that a common misconception is that Slim is spending lots of times
on new features when in fact they are primarily concerned with core features
and stability. All of these funky features are being developed by 3rd party
folks.

It's unrealistic to believe that Slim is going to spend a lot of resources
on the current 5x branch when major back end overhauling is needed. The
current architecture is just not good at handling the massive libraries that
more and more users have acquired.


> -----Original Message-----
> From: discuss-bounces-***@public.gmane.org
> [mailto:discuss-bounces-***@public.gmane.org] On Behalf Of
> Graham Ridgway at home
> Sent: Friday, January 07, 2005 12:12 PM
> To: Slim Devices Discussion
> Subject: Re: [slim] A user's perspective
>
> I guess that was one of my main points in starting the thread.
>
> 1. for me the experience is good, but not great like it used
> to be (and I don't get drop-outs).
> 2. I assume that the clever people at slim devices (and I do
> mean that, it's very hard not to sound sarcastic over email)
> are doing their stuff from a market/marketing perspective.
> They have chosen their target audience. To me (as a user)
> the whole opensource/linux thing is a complete red-herring
> (good to see that publication back by the way). Although I
> would like to think I'm really into funky features, plugins
> and the latest bits, I'm not!
> I just want my music, easily playable round the house (and in
> my car), sounding good and easily accessed by me and my family.
>
> Graham

[ron thigpen]

Bart Maguire wrote:

> In particular I am practically unable to make a playlist, the interface via
> the remote is far too slow and the web interface is also far too slow
> and requires the mouse. I don't use a mouse. For our New Years Day
> party I gave up - I went back to my old Winamp system, made a 10
> hour playlist in about 5 minutes [...]

Winamp does support saving M3U and PLS playlist files. If that's your
preferred interface for creating playlists, then why not build them
there and save to the SlimServer's playlist folder?

Granted, library management is not SS's strong suit, but it's not
supposed to be. It's also not a ripper, an encoder, a burner or a
general purpose web server. It's all about getting the content off the
PC and into the rest of the home. Personally, I use a small host of
specialized applications to create and manage my music library. Each
does one or a few things well, and leaves the rest to something else.
SlimServer is one of those apps. Some like the fully integrated iTunes
approach, but I'm happier with a different approach.

--rt

[Ralph Edington]

> Granted, library management is not SS's strong suit, but it's not
> supposed to be. It's also not a ripper, an encoder, a burner or a
> general purpose web server.

Ron, I couldn't agree more. To have one program that does it all is,
unfortunately, asking too much.

Speaking of playlists, I'm shocked at how poorly 99.9% of programs handle
playlists. I was looking for a long time for a program that could take an
existing M3U file, then show me, hierarchically and graphically vis-a-vis my
entire library, what that playlist contained, and then let me modify the
M3U, again graphically and hierarchically.

The closest I came was the Muzicman program (www.muzicman.com). Its "Library
Views" are pretty darn cool -- you can manage all your "playlists" as
"library views" (graphically and hierarchically). You still have to take
that last step of saving the library view to m3u, but for my money it beats
anything else.

Although it's not perfect, I use Muzicman religiously to manage my library
and playlists. I'd be lost without it.

The fishbone skin is nice in that it allows you to remove, say, an artist or
album from a playlist -- but it doesn't show you explicitly that that album
or artist is even IN the playlist in the first place. And in a large
playlist, of course, it's difficult to "see" what's in it. That's what I
mean by "graphically and hierarchically".

If anyone has any other suggestions for awesome playlist management
software, I'm sure we'd all like to hear them. I know I would.

RE

[Andrew Lucas]

Hi,

After several succesful parties over the festive period where my squeeze's
did a great job (thanks slimdevices), only one thing bugged me a bit and I
wondered if there was a current way of doing it, if not I would like to
offer this as a feature request.

After painstakingly building a playlist (well, more like randomly selecting
a bunch of albums), someone all excited would have searched for the
favourite tune and then hit play now.

This is great but then my playlist has gone and I would have to repeat the
exercise.

After having to do this many many times I hid the pc so I could get stuck
into the alcohol!!

What struck me was that if the behaviour of the 'play now' arrow could be
configured to be 'play next', in that the selected track was inserted into
position #2 in the playlist, in front of the existing #2 so everything else
gets bumbed down one position, the selected track would play soon enough to
satisfy without overly affecting the flow of the tunes and the old playlist
would continue on afterwards...this would ensure no interruptions to my flow
of beer also..

I appreciate that I could teach folks how to use the '+' button instead then
move the track up the playlist with the arrows but this is a bit of a pain
to be honest..to much clicking & refreshing.

Thanks
Andy

[Bart Maguire]

Yes, thanks for the suggestions that I make the playlists in Winamp (or
iTunes, or whatever) and open them in Slimserver. This will work, of
course, and may be the way forward, but it would be better it I could do
it within Slimserver. If the web interface was keyboard-shortcut
enabled, if moving tracks around the playlist didn't involve moving
them one place at a time and waiting for a refresh(!) I would be
happier. If the software was properly integrated into the shell so that I
could use the native file search and management facilities and then
send tracks to the playlist, that would be best.

[John L Fjellstad]

On Wed, Jan 05, 2005 at 08:28:34PM -0000, Bart Maguire wrote:

> happier. If the software was properly integrated into the shell so that I
> could use the native file search and management facilities and then
> send tracks to the playlist, that would be best.

Which shell, though? Would you be happy if they integrated it with the
KDE shell on Linux?

--
John L. Fjellstad
web: http://www.fjellstad.org/ Quis custodiet ipsos custodes

[Mike Kozlowski]

On Wed, 5 Jan 2005, Bart Maguire wrote:

> Yes, thanks for the suggestions that I make the playlists in Winamp (or
> iTunes, or whatever) and open them in Slimserver. This will work, of
> course, and may be the way forward, but it would be better it I could do
> it within Slimserver. If the web interface was keyboard-shortcut
> enabled, if moving tracks around the playlist didn't involve moving
> them one place at a time and waiting for a refresh(!) I would be
> happier. If the software was properly integrated into the shell so that I
> could use the native file search and management facilities and then
> send tracks to the playlist, that would be best.

Welcome to the world of Web interfaces. They have disadvantages, yes, but
they also have advantages -- I haven't seen a desktop app yet with the
same ease of navigation of SlimServer, or the same combination of
simplicity and attractiveness.

--
Mike Kozlowski
http://www.klio.org/mlk/

[Ralph Edington]

I seem to not be able to find the area of the server setup that allowed for
a scheduled nightly rescan of the music library. Was this taken out of
5.4.1? I'm using one of the nightly builds, from 12/26 I think.

Thanks,

RE

[kdf]

Quoting Ralph Edington <ralph-uL54E0APr9RWk0Htik3J/***@public.gmane.org>:

>
> I seem to not be able to find the area of the server setup that allowed for
> a scheduled nightly rescan of the music library. Was this taken out of
> 5.4.1? I'm using one of the nightly builds, from 12/26 I think.
>

it should be in server settings->plugins. it wasn't taken out intentionally at
any point. There was a time when plugin settings were not loading correctly in
the 6.0 builds, but this should not have been the case in any of the 5.4.1
builds.

-kdf

[Ralph Edington]

Thanks, kdf, I've got it now!

> -----Original Message-----
> From: discuss-bounces-***@public.gmane.org
> [mailto:discuss-bounces-***@public.gmane.org]On Behalf Of kdf
> Sent: Wednesday, January 05, 2005 7:28 PM
> To: Slim Devices Discussion
> Subject: Re: [slim] Scheduled rescan?
>
>
> Quoting Ralph Edington <ralph-uL54E0APr9RWk0Htik3J/***@public.gmane.org>:
>
> >
> > I seem to not be able to find the area of the server setup that
> allowed for
> > a scheduled nightly rescan of the music library. Was this taken out of
> > 5.4.1? I'm using one of the nightly builds, from 12/26 I think.
> >
>
> it should be in server settings->plugins. it wasn't taken out
> intentionally at
> any point. There was a time when plugin settings were not
> loading correctly in
> the 6.0 builds, but this should not have been the case in any of the 5.4.1
> builds.
>
> -kdf
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/discuss
>

[Ralph Edington]

After months of playing with slimserver and softsqueeze (and drooling), I
finally received my christmas present today (black squeezebox) and hooked it
up.

OK, so, I don't have a wireless network -- I'm using wired. But still,
installation took all of about 30 seconds. Worked flawlessly.
Mindbogglingly simple and fast. It's smaller and slimmer than I expected,
very neat and trim -- truly a "slim device".

I'm also happy to report that synching between Softqueeze and the Squeezebox
is working perfectly as well! What a relief. It even synched correctly
starting with the first song (which I had heard was a known issue).

I did have one glitch, but that's because I was using my PC a bit overly
much. Interestingly, but not unexpectedly, that caused the softsqueeze and
the squeezebox to become unsynched. Pressing >> solved that problem.

========================================

My only complaint is that the "universal remote" for my stupid Sony
STR-DE685 receiver doesn't include codes for a JVC DVD Player, so I can't
integrate the squeezer into my "universal remote"...

If anyone has any JVC DVD player codes for a Sony remote control, I'd be
happy to hear them.

Or, perhaps some other choices in addition to "jvc_dvd" on the squeeze setup
would be nice, but I guess I can't complain...

Thanks, Slim Devices -- Good Job!!!

Ralph Edington

[Ralph Edington]

Regarding synchronization:

Despite my comments below, after playing with it for a whole day, I now find
that synchronization between Softsqueeze and my new Squeezebox is somewhat
shaky.

I understand that it must be a hard thing to do, however...

My question for the community is, does synchronization between hardware
players work any better? Or is this as good as it gets? And is there hope
on the horizon for better syncing between the hard and the soft players?
(Richard T., sorry to bug you, but...)

I was really hoping to purchase more squeezeboxen for whole-house audio, but
the synchronization between softsqueeze and squeezebox is so unacceptable
that if this is as good as it gets, I would rather run speaker cables
everywhere for whole house audio.

(Of course, I'm very much hoping the community will respond that syncing
between hardware players works flawlessly.)

Synchronization seems fine sometimes, but as new songs are played, the
synchronization goes randomly off. Not by much, but enough to create
unacceptable "echos" between rooms of my house (which actually sound kind of
cool, sometimes -- depending on the music...) Clicking to >> "next song"
usually (but not always!) fixes the problem, but that's not much of a
long-term fix.

FYI, I'm running:

-- the 1/6/2005 nightly build of slimserver on windows
-- Java 1.5.0
-- the MP3 plug-in for Java
-- SoftSqueeze 1.15
-- and my audio is set to "Primary Sound Driver"
-- My single squeezebox is running as a wired client

Thanks for any help, advice or suggestions you can give...

Ralph E

> -----Original Message-----
> From: Ralph Edington [mailto:ralph-uL54E0APr9RWk0Htik3J/***@public.gmane.org]
> Sent: Wednesday, January 05, 2005 6:52 PM
> To: Slim Devices Discussion
> Subject: First Impressions
>
>
> After months of playing with slimserver and softsqueeze (and
> drooling), I finally received my christmas present today (black
> squeezebox) and hooked it up.
>
> OK, so, I don't have a wireless network -- I'm using wired. But
> still, installation took all of about 30 seconds. Worked
> flawlessly. Mindbogglingly simple and fast. It's smaller and
> slimmer than I expected, very neat and trim -- truly a "slim device".
>
> I'm also happy to report that synching between Softqueeze and the
> Squeezebox is working perfectly as well! What a relief. It even
> synched correctly starting with the first song (which I had heard
> was a known issue).
>
> I did have one glitch, but that's because I was using my PC a bit
> overly much. Interestingly, but not unexpectedly, that caused
> the softsqueeze and the squeezebox to become unsynched. Pressing
> >> solved that problem.
>
> ========================================
>
> My only complaint is that the "universal remote" for my stupid
> Sony STR-DE685 receiver doesn't include codes for a JVC DVD
> Player, so I can't integrate the squeezer into my "universal remote"...
>
> If anyone has any JVC DVD player codes for a Sony remote control,
> I'd be happy to hear them.
>
> Or, perhaps some other choices in addition to "jvc_dvd" on the
> squeeze setup would be nice, but I guess I can't complain...
>
> Thanks, Slim Devices -- Good Job!!!
>
> Ralph Edington
>
>

[Richard Titmuss]

Ralph Edington wrote:

>Regarding synchronization:
>
>Despite my comments below, after playing with it for a whole day, I now find
>that synchronization between Softsqueeze and my new Squeezebox is somewhat
>shaky.
>
>I understand that it must be a hard thing to do, however...
>
>
Yes, it is proving very hard to get this working consistently for
everyone :(

>My question for the community is, does synchronization between hardware
>players work any better? Or is this as good as it gets? And is there hope
>on the horizon for better syncing between the hard and the soft players?
>(Richard T., sorry to bug you, but...)
>
>
I have found that synchronization between the hardware players works
very well (if it didn't I would have stopped looking for sync bugs in
Softsqueeze long ago!). When I was initially working on sync I had two
hardware players on my desk and they always sync'd perfectly. I think
the only times you may have problems is if you listen to Internet Radio
or long tracks with sync, the players might slowly drift apart.

>I was really hoping to purchase more squeezeboxen for whole-house audio, but
>the synchronization between softsqueeze and squeezebox is so unacceptable
>that if this is as good as it gets, I would rather run speaker cables
>everywhere for whole house audio.
>
>
For me the big advantage of adding more squeezeboxes is that you don't
have to listen to the same music everywhere, you can have different
music in different rooms.

>(Of course, I'm very much hoping the community will respond that syncing
>between hardware players works flawlessly.)
>
>Synchronization seems fine sometimes, but as new songs are played, the
>synchronization goes randomly off. Not by much, but enough to create
>unacceptable "echos" between rooms of my house (which actually sound kind of
>cool, sometimes -- depending on the music...) Clicking to >> "next song"
>usually (but not always!) fixes the problem, but that's not much of a
>long-term fix.
>
>
I have been working with Russell over the Christmas holidays on this
very problem. Synchronization with Softsqueeze and Squeezebox works fine
for me 99% of the time, so it is difficult for me to debug the problem -
to be honest it was difficult to debug even when it was not working at
all. Unfortunately (or fortunately depending on your view point!)
Russell is now finding that sync is working for him, so I am looking for
more volunteers to help solve this. I am a little short of time right
now, but hope next week to release another version of Softsqeeze with
some additional debugging information to help track down this problem.

When the sync is off which player is ahead? Does this seem to happen
with some songs and not others, or is it completely random?

Regards,
Richard

>FYI, I'm running:
>
>-- the 1/6/2005 nightly build of slimserver on windows
>-- Java 1.5.0
>-- the MP3 plug-in for Java
>-- SoftSqueeze 1.15
>-- and my audio is set to "Primary Sound Driver"
>-- My single squeezebox is running as a wired client
>
>Thanks for any help, advice or suggestions you can give...
>
>Ralph E
>
>

[Anthony James]

On Fri, 07 Jan 2005 09:36:09 +0000, Richard Titmuss
<richard_titmuss-/E1597aS9LT10XsdtD+***@public.gmane.org> wrote:
>
> When the sync is off which player is ahead? Does this seem to happen
> with some songs and not others, or is it completely random?
>

Richard - how would you like reports on this. I use synch quite
frequently and I would say that on my system it is rarely acceptable
between softsqueeze and wired squeezebox. The location of SB2
(Wireless) makes it much more difficult to tell how good it is between
the 2 H/W players.

Can you outline the info you want and the form you want it in and i'll
start to make some notes. My sych error varies between an echo, a
beat (which sounds very odd) and a good few seconds. When out by that
much it seems to stay very out even after a change of song.

[Ken Veasey]

Synchronisation between multiple hardware SBs is pretty much flawless.
I have two in adjoining rooms, so its easy to hear any disparity. Its
fair to say they play for hours without problems. I can't claim that
they are 100% faultless, but what is!

So don't let your experience with Softsqueeze nd Squeezebox put you
off.


Ken


On Thu, 06 Jan 2005 21:45:40 -0800, you wrote:

>
>Regarding synchronization:
>
>Despite my comments below, after playing with it for a whole day, I now find
>that synchronization between Softsqueeze and my new Squeezebox is somewhat
>shaky.
>
>I understand that it must be a hard thing to do, however...
>
>My question for the community is, does synchronization between hardware
>players work any better? Or is this as good as it gets? And is there hope
>on the horizon for better syncing between the hard and the soft players?
>(Richard T., sorry to bug you, but...)
>
>I was really hoping to purchase more squeezeboxen for whole-house audio, but
>the synchronization between softsqueeze and squeezebox is so unacceptable
>that if this is as good as it gets, I would rather run speaker cables
>everywhere for whole house audio.
>
>(Of course, I'm very much hoping the community will respond that syncing
>between hardware players works flawlessly.)
>
>Synchronization seems fine sometimes, but as new songs are played, the
>synchronization goes randomly off. Not by much, but enough to create
>unacceptable "echos" between rooms of my house (which actually sound kind of
>cool, sometimes -- depending on the music...) Clicking to >> "next song"
>usually (but not always!) fixes the problem, but that's not much of a
>long-term fix.
>
>FYI, I'm running:
>
>-- the 1/6/2005 nightly build of slimserver on windows
>-- Java 1.5.0
>-- the MP3 plug-in for Java
>-- SoftSqueeze 1.15
>-- and my audio is set to "Primary Sound Driver"
>-- My single squeezebox is running as a wired client
>
>Thanks for any help, advice or suggestions you can give...
>
>Ralph E
>
>> -----Original Message-----
>> From: Ralph Edington [mailto:ralph-uL54E0APr9RWk0Htik3J/***@public.gmane.org]
>> Sent: Wednesday, January 05, 2005 6:52 PM
>> To: Slim Devices Discussion
>> Subject: First Impressions
>>
>>
>> After months of playing with slimserver and softsqueeze (and
>> drooling), I finally received my christmas present today (black
>> squeezebox) and hooked it up.
>>
>> OK, so, I don't have a wireless network -- I'm using wired. But
>> still, installation took all of about 30 seconds. Worked
>> flawlessly. Mindbogglingly simple and fast. It's smaller and
>> slimmer than I expected, very neat and trim -- truly a "slim device".
>>
>> I'm also happy to report that synching between Softqueeze and the
>> Squeezebox is working perfectly as well! What a relief. It even
>> synched correctly starting with the first song (which I had heard
>> was a known issue).
>>
>> I did have one glitch, but that's because I was using my PC a bit
>> overly much. Interestingly, but not unexpectedly, that caused
>> the softsqueeze and the squeezebox to become unsynched. Pressing
>> >> solved that problem.
>>
>> ========================================
>>
>> My only complaint is that the "universal remote" for my stupid
>> Sony STR-DE685 receiver doesn't include codes for a JVC DVD
>> Player, so I can't integrate the squeezer into my "universal remote"...
>>
>> If anyone has any JVC DVD player codes for a Sony remote control,
>> I'd be happy to hear them.
>>
>> Or, perhaps some other choices in addition to "jvc_dvd" on the
>> squeeze setup would be nice, but I guess I can't complain...
>>
>> Thanks, Slim Devices -- Good Job!!!
>>
>> Ralph Edington
>>
>>
>
>_______________________________________________
>Discuss mailing list
>Discuss-***@public.gmane.org
>http://lists.slimdevices.com/lists/listinfo/discuss
>
>
>----------------------------------------------------
>This message has been processed by Firetrust Benign.

[thnmnt]

i have a wireless sqeezebox that's in a not-always perfect reception area of
the house. trying to sync it with the wired sb in my office makes both boxes
respond very sluggishly and the sync never really gets going bc the wireless
one has so many dropouts. (without sync my wirelss box works fine) i have
asked the question before but is there a wireless signal strength threshold
below which sync is not considered possible? my wireless sb is usually
between 20-40% signal. solo operation is usually no problem at this level.

t
----- Original Message -----
From: "Ken Veasey" <k.veasey-***@public.gmane.org>
To: "Slim Devices Discussion" <discuss-***@public.gmane.org>
Sent: Friday, January 07, 2005 4:38 AM
Subject: Re: [slim] RE: First Impressions -- Synchronization


Synchronisation between multiple hardware SBs is pretty much flawless.
I have two in adjoining rooms, so its easy to hear any disparity. Its
fair to say they play for hours without problems. I can't claim that
they are 100% faultless, but what is!

So don't let your experience with Softsqueeze nd Squeezebox put you
off.


Ken


On Thu, 06 Jan 2005 21:45:40 -0800, you wrote:

>
>Regarding synchronization:
>
>Despite my comments below, after playing with it for a whole day, I now
find
>that synchronization between Softsqueeze and my new Squeezebox is somewhat
>shaky.
>
>I understand that it must be a hard thing to do, however...
>
>My question for the community is, does synchronization between hardware
>players work any better? Or is this as good as it gets? And is there hope
>on the horizon for better syncing between the hard and the soft players?
>(Richard T., sorry to bug you, but...)
>
>I was really hoping to purchase more squeezeboxen for whole-house audio,
but
>the synchronization between softsqueeze and squeezebox is so unacceptable
>that if this is as good as it gets, I would rather run speaker cables
>everywhere for whole house audio.
>
>(Of course, I'm very much hoping the community will respond that syncing
>between hardware players works flawlessly.)
>
>Synchronization seems fine sometimes, but as new songs are played, the
>synchronization goes randomly off. Not by much, but enough to create
>unacceptable "echos" between rooms of my house (which actually sound kind
of
>cool, sometimes -- depending on the music...) Clicking to >> "next song"
>usually (but not always!) fixes the problem, but that's not much of a
>long-term fix.
>
>FYI, I'm running:
>
>-- the 1/6/2005 nightly build of slimserver on windows
>-- Java 1.5.0
>-- the MP3 plug-in for Java
>-- SoftSqueeze 1.15
>-- and my audio is set to "Primary Sound Driver"
>-- My single squeezebox is running as a wired client
>
>Thanks for any help, advice or suggestions you can give...
>
>Ralph E
>
>> -----Original Message-----
>> From: Ralph Edington [mailto:ralph-uL54E0APr9RWk0Htik3J/***@public.gmane.org]
>> Sent: Wednesday, January 05, 2005 6:52 PM
>> To: Slim Devices Discussion
>> Subject: First Impressions
>>
>>
>> After months of playing with slimserver and softsqueeze (and
>> drooling), I finally received my christmas present today (black
>> squeezebox) and hooked it up.
>>
>> OK, so, I don't have a wireless network -- I'm using wired. But
>> still, installation took all of about 30 seconds. Worked
>> flawlessly. Mindbogglingly simple and fast. It's smaller and
>> slimmer than I expected, very neat and trim -- truly a "slim device".
>>
>> I'm also happy to report that synching between Softqueeze and the
>> Squeezebox is working perfectly as well! What a relief. It even
>> synched correctly starting with the first song (which I had heard
>> was a known issue).
>>
>> I did have one glitch, but that's because I was using my PC a bit
>> overly much. Interestingly, but not unexpectedly, that caused
>> the softsqueeze and the squeezebox to become unsynched. Pressing
>> >> solved that problem.
>>
>> ========================================
>>
>> My only complaint is that the "universal remote" for my stupid
>> Sony STR-DE685 receiver doesn't include codes for a JVC DVD
>> Player, so I can't integrate the squeezer into my "universal remote"...
>>
>> If anyone has any JVC DVD player codes for a Sony remote control,
>> I'd be happy to hear them.
>>
>> Or, perhaps some other choices in addition to "jvc_dvd" on the
>> squeeze setup would be nice, but I guess I can't complain...
>>
>> Thanks, Slim Devices -- Good Job!!!
>>
>> Ralph Edington
>>
>>
>
>_______________________________________________
>Discuss mailing list
>Discuss-***@public.gmane.org
>http://lists.slimdevices.com/lists/listinfo/discuss
>
>
>----------------------------------------------------
>This message has been processed by Firetrust Benign.

[Michael Scott]

Quoting Bart Maguire <bartmaguire-/E1597aS9LT10XsdtD+***@public.gmane.org>:

> it within Slimserver. If the web interface was keyboard-shortcut
> enabled, if moving tracks around the playlist didn't involve moving
> them one place at a time and waiting for a refresh(!) I would be

That is no simple task in a web interface (unless you load up on java stuff,
which has it's own problems).

> happier. If the software was properly integrated into the shell so that
> I could use the native file search and management facilities and then
> send tracks to the playlist, that would be best.

Yes, but into WHAT shell would you integrate it? Think multi-platform and
you'll see that is unreasonable. The Windows shell, Mac OS, X86, OS/2? Not
everybody runs the same OS and slimserver runs on a lot of different platforms!

Because it's open source, you are welcome to write a module to do this and maybe
even find others who would use it. If you do, don't forget to include the GEM
desktop interface on MS-DOS 6.0. :-)

----------------------
- Mike Scott
- mscott-7fCT3W/***@public.gmane.org

[kdf]

Quoting Michael Scott <mscott-7fCT3W/***@public.gmane.org>:

> Quoting Bart Maguire <bartmaguire-/E1597aS9LT10XsdtD+***@public.gmane.org>:
>
> > it within Slimserver. If the web interface was keyboard-shortcut
> > enabled, if moving tracks around the playlist didn't involve moving
> > them one place at a time and waiting for a refresh(!) I would be
>
> That is no simple task in a web interface (unless you load up on java stuff,
> which has it's own problems).

actually browsers have keyboard control built-in. its just a painful overuse of
the tab key in order to navigate the links.
-kdf

[Dan Sully]

* kdf shaped the electrons to say...

>> > it within Slimserver. If the web interface was keyboard-shortcut
>> > enabled, if moving tracks around the playlist didn't involve moving
>> > them one place at a time and waiting for a refresh(!) I would be
>>
>> That is no simple task in a web interface (unless you load up on java stuff,
>> which has it's own problems).
>
>actually browsers have keyboard control built-in. its just a painful overuse of
>the tab key in order to navigate the links.

Or if someone is creative and looks at how GMail is doing keyboard (non-tab)
shortcuts with their cross platform Javascript, that would work too. :)

-D
--
<iNoah> my pdp goes to 11.

[Phil Thien]

Exactly. I couldn't agree more with this post. Initial reaction from new
users is interesting, but so often they tell you how the product didn't meet
their original expectations ("disappointed because no native Windows
software with Windows interface," for example). It is only after they've
used the product for several days to months that they really begin the
underlying beauty of open-source cross-platform. I suppose some of them,
due to the fact that they really only use Windows computers, will never see
the beauty of cross-platform.

I wonder how many programmers are created by projects like this. You know,
someone identifies a change they'd like, can't find anyone else interested
in implementing it, and therefore decides to learn to do it themselves.
There have got to be a few.

Keep it open-source cross-platform!

I have used it (Slimp3) every day for at least two+ years and would never do
without.

-Phil

----- Original Message -----
From: "Michael Scott" <mscott-7fCT3W/***@public.gmane.org>
To: "Slim Devices Discussion" <discuss-***@public.gmane.org>
Sent: Thursday, January 06, 2005 4:25 PM
Subject: Re: [slim] A user's perspective


> Because it's open source, you are welcome to write a module to do this and
> maybe
> even find others who would use it. If you do, don't forget to include the
> GEM
> desktop interface on MS-DOS 6.0. :-)
>
> ----------------------
> - Mike Scott
> - mscott-7fCT3W/***@public.gmane.org
>
>

[Brian Abbott, ACA Systems]

I think your post illustrates very well the dilemma faced in the longer
term.

Most people on this list (and maybe most SB owners?) appear to me to be
'tinkerers'. I don't use this word pejoratively (I tinker a lot myself!)
but to differentiate from the average 'person out there' who wants to 'plug
it in, switch it on and listen' and whose eyes glaze over if you use terms
like Perl, IP Address, MS-DOS, Linux, 802.11 (you get the idea ...)

The bottom line is that SB /SS is never going to make the breakthrough into
a mass market until/unless the average 'person out there' is catered for -
that is, with something that works 'out of the box' 99% of the time. But
then, maybe the people on this list aren't bothered about that anyway? (says
he being deliberately provocative <g>)

Cheers

Phil Thien wrote:
> Exactly. I couldn't agree more with this post. Initial reaction
> from new users is interesting, but so often they tell you how the
> product didn't meet their original expectations ("disappointed
> because no native Windows software with Windows interface," for
> example). It is only after they've used the product for several days
> to months that they really begin the underlying beauty of open-source
> cross-platform. I suppose some of them, due to the fact that they
> really only use Windows computers, will never see the beauty of
> cross-platform.
>
> I wonder how many programmers are created by projects like this. You
> know, someone identifies a change they'd like, can't find anyone else
> interested in implementing it, and therefore decides to learn to do
> it themselves.
> There have got to be a few.
>
> Keep it open-source cross-platform!
>
> I have used it (Slimp3) every day for at least two+ years and would
> never do without.
>
> -Phil

============
Brian Abbott
============

[Andy Bunn]

> Most people on this list (and maybe most SB owners?) appear to me to be
> 'tinkerers'. I don't use this word pejoratively (I tinker a lot myself!)

There is no way for the list members to know what percentage of SB like
tinkering and configuring their gear. The slim staff might have a better
idea. It's hard for anybody who enjoys mucking about with their fstab to
remember that 99.9999999% of computer users have no such aspirations. I do
enjoy that kinda stuff, but I have a full time job and two small kids. I'm
pleased to report that my SB runs _perfectly_ out of the box. Even tho' I'm
on the list to keep my hand in, I'm for all intents and purposes a happy
noob who will not contribute code or ask (whine) for new features. Go slim,
ya'll rock...

Regards,
-Andy

[Joe Craig]

> That's probably true. But then I think it's true for all networked
> media solutions at present. Until such time as wireless network
> solutions are truly idiot-proof and can be handled by someone for whom
> the computer is a tool rather than a career or a hobby, devices such as
> Squeezebox will tend to be used by technophiles

I think that Tivo is about as close to "idiot proof" as anything that
I've ever seen.

--


Joe

[Jules Taplin]

Yeah. It's pretty close.

Although... A TiVo with a disk failure can be a pretty frustrating
beast. If it's in a data area, they skip, and pause, and generally
behave badly.

Not that they could have done much about the problem... But TiVo's hide
so much of their complexity that the only way you'll know that was the
problem is if you've hacked it to get a console to it ;)


-- Jules

Joe Craig wrote:

>>That's probably true. But then I think it's true for all networked
>>media solutions at present. Until such time as wireless network
>>solutions are truly idiot-proof and can be handled by someone for whom
>>the computer is a tool rather than a career or a hobby, devices such as
>>Squeezebox will tend to be used by technophiles
>>
>>
>
>I think that Tivo is about as close to "idiot proof" as anything that
>I've ever seen.
>
>
>

[Jeff Allison]

Brian Abbott, ACA Systems wrote:

> The bottom line is that SB /SS is never going to make the
> breakthrough into a mass market until/unless the average
> 'person out there' is catered for - that is, with something
> that works 'out of the box' 99% of the time. But then,
> maybe the people on this list aren't bothered about that
> anyway? (says he being deliberately provocative <g>)

That's probably true. But then I think it's true for all networked
media solutions at present. Until such time as wireless network
solutions are truly idiot-proof and can be handled by someone for whom
the computer is a tool rather than a career or a hobby, devices such as
Squeezebox will tend to be used by technophiles. Hopefully that's not a
problem, and hopefully the folks at Slim Devices are making a
comfortable living off of their cool technology.

On the topic of "idiot-proof", anyone see Bill Gates' performance at CES
the other day? The big keynote speech around Windows Media Center
featured a locked-up system that wouldn't respond to Gates' remote
("must be the wrong remote," said Bill) and a BSOD during a game
preview. I wonder if the mass market can get that stuff to work when
the drones at MS can't do it on the big stage.

- Jeff

[Graham Ridgway at home]

That's me! I don't see the beauty of open-source cross platform! Really I
don't.

You'll need to elucidate!

Graham
----- Original Message -----
From: "Phil Thien" <jpt-fA3hFiH2ocJWk0Htik3J/***@public.gmane.org>
To: "Slim Devices Discussion" <discuss-***@public.gmane.org>
Sent: Friday, January 07, 2005 1:52 PM
Subject: Re: [slim] A user's perspective


> It is only after they've used the product for several days to months that
> they really begin the underlying beauty of open-source cross-platform. I
> suppose some of them, due to the fact that they really only use Windows
> computers, will never see the beauty of cross-platform.

[Bart Maguire]

<?xml version="1.0" ?><html>
<head>
<title></title>
</head>
<body>
<div align="left"><font face="Arial"><span style="font-size:10pt">I am not a programmer, but I can see that there might be some challenging
design/programming issues!</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">But saying that it is difficult is not a reason give up, or give your users second best...</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">I am currently using KDE on SuSE but I have also tried running Slimserver on Windows
XP (because I wanted to try to integrate MusicMagic).&#160; I might switch to RedHat soon
because SuSE doesn't install RPMs properly.</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">&gt;Which shell, though?&#160; Would you be happy if they integrated it with the</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">&gt;KDE shell on Linux?</span></font></div>
<div align="left"></div>
</body>
</html>

[kdf]

Quoting Bart Maguire <bartmaguire-/E1597aS9LT10XsdtD+***@public.gmane.org>:


> I am
> currently using KDE on SuSE but I have also tried running Slimserver on
> Windows
> XP (because I wanted to try to integrate MusicMagic). I might switch to
> RedHat soon
> because SuSE doesn't install RPMs properly.</span></font></div>
>
You can use MusicMagic under Linux as well. You just need Java and X. Most times
I run it via ssh with X forwarding and cygwin. My linux box is a server, so
I'm never sitting at the console.

In my experience, the response of the player UI is much snappier when the server
is running under Linux, or even OSX. There is no reason for Perl to run slower
under Windows, but I think there is just always more going on in a windows
system.

-kdf

[Bart Maguire]

<?xml version="1.0" ?><html>
<head>
<title></title>
</head>
<body>
<div align="left"><font face="Arial"><span style="font-size:10pt">I wish I could run Musicmagic under linux.&#160; Every time I try to load a
6.0 build I get errors related to DBI, but I don't know how to install this
modules.&#160; </span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">linux:/usr/local/slimserver # Can't locate DBI.pm in @INC (@INC </span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">contains: /usr/local/slimserver /usr/local/slimserver/CPAN </span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">/usr/local/slimserver/CPAN/arch/5.8.3/i586-linux-thread-multi ...etc</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">After Googling for help I tried perl -MCPAN -e 'install DBI' but it failed
and will now not even run.&#160; So, I put Slimserver 6.0 on a Windows XP
machine.&#160; That installed OK but will not run.&#160; When I run it it begins
scanning the music folder, scans a few albums, then the service stops.
Even if I set the service to automatically restart it never gets any further
than beginning the scan before it crashes out.</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">My Musicmagic evaluation key has nearly run out and I have never
seen it work with Slimserver.</span></font></div>
<div align="left"><br/>
</div>
<div align="left"></div>
</body>
</html>

[kdf]

Quoting Bart Maguire <bartmaguire-/E1597aS9LT10XsdtD+***@public.gmane.org>:

> scanning the music folder, scans a few albums, then the service stops.
> Even if I set the service to automatically restart it never gets any further
> than beginning the scan before it crashes out.</span></font></div>
> <div align="left"><font face="Arial"><span style="font-size:10pt">My
> Musicmagic evaluation key has nearly run out and I have never
> seen it work with Slimserver.</span></font></div>

There is a version you can run that is 5.4.1 stream. Erk, at least there was.
It seems the nightly builds prior to Dec 27 are gone. That's when the streams
split and 5.4.1 branch was not going to included musicmagic integration, which
was still somewhat experimental.

I think the problem with E-Smith is related to the perl version included on that
system. i think I recall one user mention ESmith as using 5.6 of Perl, which
is no longer supported for 6.0 builds, due to the UTF-8 Support. One possible
source of the scan crash under windows could be shortcuts. There is a known
issue with the 6.0 builds right now that causes the system to crash if it finds
a windows shortcut during the scan.

-kdf

[Michael Herger]

[..]
> I think the problem with E-Smith is related to the perl version included
> on that
> system. i think I recall one user mention ESmith as using 5.6 of Perl,

Yep. Might have been me :-/. As all the administration tools for e-smith
are written in Perl it's not easily upgreadable. A thread over at
contribs.org discussing this topic died with no result.

I compiled 5.8 manually and have it installed alongside 5.6. I therefore
have to manually change the first line in slimserver.pl...

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

[Steven Moore]

Hi,
Just like to add my mini review.
I've been using the squeezebox now for about 2 weeks and it has in the
most part performed great.
The set up was very easy, mine is a simple wired 1 squeezebox setup and
went without hassle.
It took only a day or two to master the menu system on the SB and it
has now become second nature.
The sound quality is excellent, I use mostly high rate mp3's (256 or
above) and the sound even at high volume is excellent.
I have had no dropouts.
The web interface is both clear and easy to use.
The only niggle I have had is the search song problem that some of you
might have read about in my previous posts.
This would be very confusing to the first time user, as it was to
myself when the server disconnected when searching for a song for the
first time after a rescan. Also returning an empty result when you know
the song exists would again be confusing, maybe an entry in the FAQ
would help here.
This was very annoying at first but I have learned to 'live' with it
until a new version of the server software is released with a fix.
The discussion list is also great resource.

Overall the Squeezebox is very good value for money, It has freed up my
music as promised and I look forward to new versions of the server
software.

Steven Moore

[Phillip Kerman]

> On the topic of "idiot-proof", anyone see Bill Gates'
> performance at CES
> the other day? The big keynote speech around Windows Media Center
> featured a locked-up system that wouldn't respond to Gates' remote
> ("must be the wrong remote," said Bill) and a BSOD during a game
> preview. I wonder if the mass market can get that stuff to work when
> the drones at MS can't do it on the big stage.
>


I don't know... In the last few years I've seen more BSOD during keynotes
than any other time. I really think it's a publicity stunt. Happens every
time almost--gets lots of airplay. What's the quote..? Any publicity is
good publicity.

Thanks,
Phillip