PDA

View Full Version : quick summary of 6.0 changes?



Phillip Kerman
2005-01-03, 23:49
> > 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
2005-01-04, 00:17
Quoting Phillip Kerman <lists (AT) phillipkerman (DOT) com>:

> > > 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

Robin Bowes
2005-01-04, 01:50
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
2005-01-04, 03:07
Quoting Robin Bowes <robin-lists (AT) robinbowes (DOT) com>:

> 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
2005-01-04, 04:17
kdf wrote:
> Quoting Robin Bowes
> <robin-lists (AT) robinbowes (DOT) com>:
>
> 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.

Kevin Hawkins
2005-01-04, 07:13
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

Jack Coates
2005-01-04, 08:42
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
2005-01-04, 09:14
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.

Anthony James
2005-01-04, 10:31
On Tue, 4 Jan 2005 09:05:23 -0800, Phillip Kerman
<lists (AT) phillipkerman (DOT) com> 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.

Robin Bowes
2005-01-04, 11:00
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%.

Michael Amster
2005-01-04, 11:16
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.
>
>

Steve Baumgarten
2005-01-04, 11:28
> 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.

Michael Amster
2005-01-04, 11:40
>
> 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
2005-01-04, 11:48
Quoting Robin Bowes <robin-lists (AT) robinbowes (DOT) com>:

> kdf wrote:
> > Quoting Robin Bowes
> > <robin-lists (AT) robinbowes (DOT) com>:
> >
> > 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

kdf
2005-01-04, 11:48
Quoting Michael Amster <mamster (AT) wnx (DOT) com>:
> 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
2005-01-04, 13:01
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 (AT) deane-freeman (DOT) com>
said:
> In fact, one of Dan's changes yesterday will allow a separate copy of
> SlimServer to run as a scanner only.
>
> -kdf

John S J Anderson
2005-01-04, 18:36
Michael Amster <mamster (AT) wnx (DOT) com> 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.

Pat Farrell
2005-01-14, 15:58
At 01:28 PM 1/4/2005, 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.

My old slimserver would have occasional dropouts to my wired SBx.
Of course, doing a rescan would guarentee them, but I'd hear
one every thirty minutes or so (just a guess, I never tried to time them).

The server was a 500mHz pentium III, with 768MB ram, or so.
The box was one I had laying arround.

ruinning 'top' never showed anything interesting, I expect it was just a quick
overload of some resource.

Looking at the Sbx buffer would show it getting empty. But no real
pattern I could see.

Of course, when the CPU fan burned out and took the CPU with it,
I had to replace the MB and CPU, the new one is a AMD 3200 or so
and I've not had a noticable dropout in the couple
of weeks since the replacement.

I now think that a 500 mHz CPU is too slow to be a good slimserver.
Linux Fedora Core 1, then 2, now Mandrake

Pat

David Brittain
2005-01-15, 02:17
I too was seeing dropouts on a wired squeezebox. I would get one on
average every 10 or 15 minutes. It turned out the cause was a bad
ethernet cable. I replaced this and they went away. The cable was the
one I had travelled with for the last few years, and it probably
explains why I could never hold a VPN connection for longer than an hour
from my laptop. As, since not using it, VPN is reliable too! I was very
surprised to find that a cable could apparently work well enough to
transfer significant amounts of data, but cause intermittent dropouts.

Dave

Pat Farrell wrote:

> At 01:28 PM 1/4/2005, 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.
>
>
> My old slimserver would have occasional dropouts to my wired SBx.
> Of course, doing a rescan would guarentee them, but I'd hear
> one every thirty minutes or so (just a guess, I never tried to time them).
>
> The server was a 500mHz pentium III, with 768MB ram, or so.
> The box was one I had laying arround.
>
> ruinning 'top' never showed anything interesting, I expect it was just
> a quick
> overload of some resource.
>
> Looking at the Sbx buffer would show it getting empty. But no real
> pattern I could see.
>
> Of course, when the CPU fan burned out and took the CPU with it,
> I had to replace the MB and CPU, the new one is a AMD 3200 or so
> and I've not had a noticable dropout in the couple
> of weeks since the replacement.
>
> I now think that a 500 mHz CPU is too slow to be a good slimserver.
> Linux Fedora Core 1, then 2, now Mandrake
>
> Pat
>
>
>------------------------------------------------------------------------
>
>