[SlimDevices: Beta] Re: SB1's struggling to keep up

[snarlydwarf]

dapnyc Wrote: 
> Did you ever buy a stereo component that suddenly stopped working with
> CD's? Did you ever buy a car that, after you took it to the shop to
> tune it up, suddenly didn't function with gas? My point is that they
> upgraded the software without telling customers that it would render
> their older devices effectively useless (unless you enjoy music
> dropouts). 

Not the same thing at all.  If you want an exact analogy, stick to the
facts: "I downloaded software and it didn't perform well on my hardware
as the old version" and your solution is "I should get a free hardware
upgrade"...

So when you buy Windows XP and it doesn't run on your 8088, Microsoft
should send you a new PC...  "But DOS ran just FINE and your bloated XP
doesn't!!"

No One Forced You To Upgrade.

If I bought a CD player that didn't play CD's then it wouldn't be a CD
player, would it?  If it used a MagicalWhoozitConnector and I needed a
SuperWhatzitBrand DAC to use it: then I should have figured that out
before I bought it or return it when it doesn't work.

If I paid for a Tuneup and the car stopped working: I would make them
restore it to working condition.  I sure as hell wouldn't demand that I
deserve a brand new car.

> 
> So the net is that SD should have either 1) notified users that if you
> use a Squeezebox 1 (for example), DO NOT download this new version, or
> 2) tell users that they will no longer support the Squeezebox 1, or 3)
> stop supporting an old piece of hardware but because they don't want to
> piss of customers, give them an easy upgrade path. In the technology
> space, this happens all the time

But it isn't a question of not supporting the SB1: the problem is that
the much smaller buffer of an SB1 is beginning to show as a problem as
the code gets more complex and starts demanding more CPU.  On some
server hardware there may be insufficient CPU resources to keep the
buffer full.

If you don't like the performance of 6.3, then you can certainly go
back and download another version of the software... one that works
better on your setup.

http://www.slimdevices.com/downloads/

Nothing stops you from running 5.4 if you want to.


-- 
snarlydwarf

snarlydwarf's Profile: http://forums.slimdevices.com/member.php?userid=1179
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[dapnyc]

snarlydwarf Wrote: 
> Yeah, just last week Sony sent me a PS3 because my PS2 is being phased
> out.  And Nissan sent me a new car, because the 2005 model is just,
> well, dated.
> 
> It is very normal to have an upgrade path for software.  It often costs
> a substantial sum, though, but it is usually around.
> 
> How many personal electronic -hardware- products do you get to upgrade
> at a discount?
> 
> I have never seen, say, JVC offer a new car stereo because they came
> out with a line that added MP3 reading to the CD's...
> 
> Do you really believe any business could survive giving away not only
> their software but also their hardware?

Did you ever buy a stereo component that suddenly stopped working with
CD's? Did you ever buy a car that, after you took it to the shop to
tune it up, suddenly didn't function with gas? My point is that they
upgraded the software without telling customers that it would render
their older devices effectively useless (unless you enjoy music
dropouts). 

So the net is that SD should have either 1) notified users that if you
use a Squeezebox 1 (for example), DO NOT download this new version, or
2) tell users that they will no longer support the Squeezebox 1, or 3)
stop supporting an old piece of hardware but because they don't want to
piss of customers, give them an easy upgrade path. In the technology
space, this happens all the time...


-- 
dapnyc

dapnyc's Profile: http://forums.slimdevices.com/member.php?userid=6350
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

More tuning has happend to 6.5 than 6.3, so I would hope 6.5 will be
able to support SB1s well once it is stable.  

If you find a problem on 6.5 please enable the following and report
what you see in the server log:
1) go to Server & Network Health
2) enable performance monitoring
3) go to Server Statistics.  This displays measurements of various
internal server performance figures.  
4) at the bottom of the page, enter 0.5 in the high thresholds box next
to "Set All" and then press "Set All"

This creates an entry in the log if any of the measurements on the page
exceeds 0.5 seconds.


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Michael Herger]

One thing that hasn't been discussed (if I've seen it right): FLAC isn't  
supported natively in SB1. It therefore has to be transcoded to WAV  
(double the bandwidth) or MP3 (poorer quality). I guess the first is the  
case. And wireless can't keep up with the bandwith needed. If you limit to  
320kbps it will be transcoded to MP3 and might fix your issues.


--

Michael

---
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[snarlydwarf]

Yeah, just last week Sony sent me a PS3 because my PS2 is being phased
out.  And Nissan sent me a new car, because the 2005 model is just,
well, dated.

It is very normal to have an upgrade path for software.  It often costs
a substantial sum, though, but it is usually around.

How many personal electronic -hardware- products do you get to upgrade
at a discount?

Some places have trade-ins on things like PCs: they will buy your old
one for a tiny fraction of what you paid for it and sell it to someone
else.  Some do that for things like AS/400's... I have never seen, say,
JVC offer a new car stereo because they came out with a line that added
MP3 reading to the CD's...

Do you really believe any business could survive giving away not only
their software but also their hardware?


-- 
snarlydwarf

snarlydwarf's Profile: http://forums.slimdevices.com/member.php?userid=1179
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[dapnyc]

Folks, I'm not a techie by any stretch, so I hate to intrude in the
debate, but as a s1 owner I came to this board for the same reason as
all of you: I'm trying to figure out if there is a simple fix for the
S1 constantly "hesitating" when playing music with the most recent
releases of the server.

Correct me if I'm wrong, but was anyone told that the new releases
won't work with the s1? Was anyone told that SlimDevices will no longer
support that product? I know I wasn't, and would have never upgraded if
I knew I could no longer effectively use the device.

So since the RIGHT solution is that the s1 doesn't work anymore and to
get a new device, isn't the problem with SlimDevices, and why they're
not providing free (or very inexpensive) upgrades to their latest
devices? Especially when those of us that are suffering are their early
adopters--those who helped them get traction in the marketplace.

While I'm not a technie, I did work for a technology company for a long
time, and we always provided easy migration paths when we stopped
supporting older products...

Just a thought...


-- 
dapnyc

dapnyc's Profile: http://forums.slimdevices.com/member.php?userid=6350
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Christopher Key wrote:
> The log seems to suggest that XML::Parser and YAML::Syck are either built
> correctly (or alternatively that they are not being built at all, and are
> hence being loaded sucessfully from the system CPAN path), but that most of
> the rest of the modules are failing.  I've just update slimserver.pl
> slightly so that it'll report where the modules are being loaded from
> regardless of whether some modules fail to load, so it would be interesting
> to run slimserver.pl --d_startup again.  I can't really comment of
> build-perl-modules.pl, so would suggest that until someone better qualified
> can comment, that you try installing DBD::SQLite and Compress::Zlib (and
> optionally, GD and Locale::Hebrew).

I had to manually upgrade my CPAN version, and then
hand installed DBD::SQLite  Compress::Zlib
Locale::Hebrew

and CGI::Util

So far, it is at least starting, and scanning my library.

Running 6.5b1 - 7390 - Linux - EN - iso-8859-1
which is a couple of days old. So far, it is too soon to
tell about the struggling SB1

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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

RE: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Christopher Key]

Pat Farrell wrote:
> Christopher Key wrote:
>> Could you try ./slimserver.pl --d_startup

I've reformatted the content below to make it a little more readable

> 
> (beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17>
> ./slimserver.pl --d_startup
> Got @INC containing: /home/pfarrell/incoming/SlimServer_v2006-05-17
> /usr/lib/perl5/5.8.5/i386-linux-thread-multi
> /usr/lib/perl5/5.8.5
> /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.5
> /usr/lib/perl5/site_perl
> /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.5
> /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.4
> /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.3
> /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.1
> /usr/lib/perl5/vendor_perl
> .  
> 
> Extended @INC to contain:
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-th
read-multi
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-th
read-multi/auto
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thre
ad-multi
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thre
ad-multi/auto
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-m
ulti
> /home/pfarrell/incoming/SlimServer_v2006-05-17/lib
> /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN
> /home/pfarrell/incoming/SlimServer_v2006-05-17
> /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5
> /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.5
> /usr/lib/perl5/site_perl
> /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.5
> /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.4
> /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.3
> /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.1
> /usr/lib/perl5/vendor_perl
> .  
> 
> Removing [Time::HiRes] from the symbol table - load failed.
> Removing [DBD::SQLite] from the symbol table - load failed. 
> Removing [DBI] from the symbol table - load failed. 
> Removing [DBI] from the symbol table - load failed. 
> Loaded module: [XML::Parser] ok! 
> Removing [HTML::Parser] from the symbol table - load failed. 
> Removing [HTML::Entities] from the symbol table - load failed. 
> Can't locate
> auto/Compress/Zlib/autosplit.ix in @INC (@INC contains:
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-th
read-multi
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-th
read-multi/auto
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thre
ad-multi
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thre
ad-multi/auto
>
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-m
ulti
> /home/pfarrell/incoming/SlimServer_v2006-05-17/lib
> /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN
> /home/pfarrell/incoming/SlimServer_v2006-05-17
> /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5
> /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl
> /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.5
> /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.4
> /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.3
> /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl .) at
> /usr/lib/perl5/5.8.5/AutoLoader.pm line 160.  at
> /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/Compress/Zlib.pm 
> line 15
> 
> Removing [Compress::Zlib] from the symbol table - load failed.
> Removing [Digest::base] from the symbol table - load failed.
> Removing [Digest::SHA1] from the symbol table - load failed.
> Loaded module: [YAML::Syck] ok!
> Removing [GD::Polygon] from the symbol table - load failed.
> Removing [GD::Image] from the symbol table - load failed.
> Removing [GD] from the symbol table - load failed. 
> Removing [Locale::Hebrew] from the symbol table - load failed. 
> The following modules failed to load on the first attempt: [Time::HiRes,
> DBD::SQLite, DBI, HTML::Parser, Compress::Zlib, Digest::SHA1] - will
> try again. 
> 
> The following optional modules failed to load on the first attempt:
> [GD, Locale::Hebrew] - will try again 
> 
> Loaded module: [Time::HiRes] ok!
> Loaded module: [DBI] ok!
> Loaded module: [HTML::Parser] ok!
> Loaded module: [Digest::SHA1] ok!
> The following optional modules failed to load: [GD, Locale::Hebrew]
> after their second try. 
> 
> The following modules failed to load: DBD:

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Christopher Key wrote:
 >
> Could you try ./slimserver.pl --d_startup
> 

(beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17>
./slimserver.pl --d_startup
Got @INC containing:
/home/pfarrell/incoming/SlimServer_v2006-05-17
/usr/lib/perl5/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/5.8.5
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.1
/usr/lib/perl5/vendor_perl
.

Extended @INC to contain:
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi/auto
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi/auto
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/lib
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN
/home/pfarrell/incoming/SlimServer_v2006-05-17
/usr/lib/perl5/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/5.8.5
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.1
/usr/lib/perl5/vendor_perl
.

Removing [Time::HiRes] from the symbol table - load failed.
Removing [DBD::SQLite] from the symbol table - load failed.
Removing [DBI] from the symbol table - load failed.
Removing [DBI] from the symbol table - load failed.
Loaded module: [XML::Parser] ok!
Removing [HTML::Parser] from the symbol table - load failed.
Removing [HTML::Entities] from the symbol table - load failed.
Can't locate auto/Compress/Zlib/autosplit.ix in @INC (@INC contains:
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi/auto
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi/auto
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/lib
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN
/home/pfarrell/incoming/SlimServer_v2006-05-17
/usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl .) at
/usr/lib/perl5/5.8.5/AutoLoader.pm line 160.
 at /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/Compress/Zlib.pm
line 15
Removing [Compress::Zlib] from the symbol table - load failed.
Removing [Digest::base] from the symbol table - load failed.
Removing [Digest::SHA1] from the symbol table - load failed.
Loaded module: [YAML::Syck] ok!
Removing [GD::Polygon] from the symbol table - load failed.
Removing [GD::Image] from the symbol table - load failed.
Removing [GD] from the symbol table - load failed.
Removing [Locale::Hebrew] from the symbol table - load failed.
The following modules failed to load on the first attempt: [Time::HiRes,
DBD::SQLite, DBI, HTML::Parser, Compress::Zlib, Digest::SHA1] - will try
again.

The following optional modules failed to load on the first attempt: [GD,
Locale::Hebrew] - will try again

Loaded module: [Time::HiRes] ok!
Loaded module: [DBI] ok!
Loaded module: [HTML::Parser] ok!
Loaded module: [Digest::SHA1] ok!
The following optional modules failed to load: [GD, Locale::Hebrew]
after their second try.

The following modules failed to load: DBD::SQLite Compress::Zlib

To download and compile them, please run:
/home/pfarrell/incoming/SlimServer_v2006-05-17/Bin/build-perl-modules.pl

Exiting..
(beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17>
(beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17>







-- 
Pat
http://www.pfarrell.com/music/s

RE: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Christopher Key]

Pat Farrell wrote:
> Triode wrote:
>> What does it say when you try to start the server manually with
>> ./slimserver.pl?
> 
> That's what I did in the last message
> 
> 
> ./slimserver.pl
> 
> 

Could you try ./slimserver.pl --d_startup

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Triode wrote:
> What does it say when you try to start the server manually with
> ./slimserver.pl?

That's what I did in the last message


./slimserver.pl


Can't locate auto/Compress/Zlib/autosplit.ix in @INC (@INC contains:
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi/auto
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi/auto
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/lib
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN
/home/pfarrell/incoming/SlimServer_v2006-05-17
/usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl .) at
/usr/lib/perl5/5.8.5/AutoLoader.pm line 160.
 at /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/Compress/Zlib.pm
line 15
The following modules failed to load: DBD::SQLite Compress::Zlib

To download and compile them, please run:
/home/pfarrell/incoming/SlimServer_v2006-05-17/Bin/build-perl-modules.pl




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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

Thanks interesting - your perl architecture is
"i386-linux-thread-multi".  My Mandravia 2006 is i386-linux, but it is
a never version of perl.

In this case I would have thought it should run the rpm as is without
the extra modules.  Try removing everything in the CPAN directory and
re installing the rpm.

What does it say when you try to start the server manually with
./slimserver.pl?


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Triode wrote:
> Have you run the build script (./Bin/build-perl-modules.pl) to make the
> new modules needed?

Now I have, and I'm not sure it is happy.
This seems to require root.

Warning: prerequisite AppConfig 1.55 not found.
Building..
Library for Template-Toolkit-2.14.tar.gz is OK!

then I get

All done!

Then I attempt to run it and get

Changelog2.html  Changelog5.html  convert.conf Graphics  IR
   Plugins  slimserver.pl  types.conf
(beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17>
./slimserver.pl
Can't locate auto/Compress/Zlib/autosplit.ix in @INC (@INC contains:
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi/auto
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi/auto
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-multi
/home/pfarrell/incoming/SlimServer_v2006-05-17/lib
/home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN
/home/pfarrell/incoming/SlimServer_v2006-05-17
/usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl .) at
/usr/lib/perl5/5.8.5/AutoLoader.pm line 160.
 at /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/Compress/Zlib.pm
line 15
The following modules failed to load: DBD::SQLite Compress::Zlib

To download and compile them, please run:
/home/pfarrell/incoming/SlimServer_v2006-05-17/Bin/build-perl-modules.pl



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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Triode wrote:
> Have you run the build script (./Bin/build-perl-modules.pl) to make the
> new modules needed?

No, I just did the rpm and tried to run it.

DIdn't know voodoo was needed.



> This is needed as Mandravia 2006 has chosen to build perl without
> multithread support so the architecture of the precompiled modules in
> the rpm is different from that needed for your perl.

I can try this later today

Pat



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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

Have you run the build script (./Bin/build-perl-modules.pl) to make the
new modules needed?

This is needed as Mandravia 2006 has chosen to build perl without
multithread support so the architecture of the precompiled modules in
the rpm is different from that needed for your perl.


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Since I've been having this problem as well, Triode suggested I try
the 6.5 build. rather than the current 6.2.xxx

I had a 6.5 working a while back, but the current nightly on 6.5
does not execute. I installed via RPM onto my Mandriva 2006 system
and it is whining about perl modules not being available.

Usually RPMs just work. Is this a known problem of the 6.5 RPM or
something wacky about my system or ...???

Thanks
Pat

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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[hickinbottoms]

Triode Wrote: 
> Looks like scrobbler could be improved, but the internal server
> functions are better.  Hopefully the web page one can be improved
> further with the new database code which is comming.
> 
> 
> This should not have happended - did anyone else see it?

If it helps I'll try to repeat that (I've a copy of my old preferences
file), and if I can I'll raise a bug. I'll sanitise my preferences for
anything security-related and attach it to the bug (assuming I can
reproduce it).

I'd forgotten just how much configuration I'd done in SlimServer and
for my players until I had to redo it all over the weekend (I'm not
complaining - that's what you expect with the development trunk, after
all).


-- 
hickinbottoms

Stuart
-"Never put off until tomorrow what you can put off until the day after
- with Lazy Searching!"-

hickinbottoms's Profile: http://forums.slimdevices.com/member.php?userid=255
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

Triode Wrote: 
> This should not have happended - did anyone else see it?

Mine upgraded fine on windows, Thanks for all the improvements.

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

Looks like scrobbler could be improved, but the internal server
functions are better.  Hopefully the web page one can be improved
further with the new database code which is comming.

hickinbottoms Wrote: 
> (by the way, I had to delete my old prefs as the server kept complaining
> they were corrupt - presumably because of the different choice of YAML
> module, but it didn't handle the upgrade very gracefully).
> 
This should not have happended - did anyone else see it?


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[hickinbottoms]

Triode Wrote: 
> Stuart - if you try the latest 6.5 (today's nightly), you should find
> the writePrefs delay is much reduced.  Do you see this?

I've rerun a similar type of test with r7430 (I'd backed out the patch
to HTTP.pm so it was unmodified from the Subversion version). 

As before the server is a lowly 460MHz PentiumII running Gentoo Linux,
with MySQL as the database server. I have an SB1(G). The music is all
streaming in PCM (from FLAC) over wireless (802.11b).

I've not snipped any lines out of the log this time - this should be
complete for the actions I was performing. I've attached an annotated
version of that log.

In summary, it seems to be much better. I only got it to drop out when
initiating a "browse albums" from the web interface - this happened a
couple of times. I couldn't get it to drop out when doing anything
else, and this was while using the web interface quite heavily while
playing.

Looking at the log, the only warnings now >0.5s were in
Slim::Web::HTTP::processHTTP and
Slim::Control::Commands::playlistXtracksCommand. There were no warnings
about saving the prefs, so those recent changes seemed to have done the
trick (by the way, I had to delete my old prefs as the server kept
complaining they were corrupt - presumably because of the different
choice of YAML module, but it didn't handle the upgrade very
gracefully).

On the basis of this performance I'm now very happy with it - whereas
previously I'd avoid using the web interface because of the dropouts, I
am now confident enough to use it.

Thanks very much for the improvements - I'm sure they'll benefit a lot
of people.

If you want me to do any further testing then just say what you'd like
done.


+---+
|Filename: 7430.txt |
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=1338|
+---+

-- 
hickinbottoms

Stuart
-"Never put off until tomorrow what you can put off until the day after
- with Lazy Searching!"-

hickinbottoms's Profile: http://forums.slimdevices.com/member.php?userid=255
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[hickinbottoms]

Triode Wrote: 
> Stuart - if you try the latest 6.5 (today's nightly), you should find
> the writePrefs delay is much reduced.  Do you see this?

Just picked up this message - I'll give that a try tonight and report
back to this thread. Thanks for the pointer to the update.


-- 
hickinbottoms

Stuart
-"Never put off until tomorrow what you can put off until the day after
- with Lazy Searching!"-

hickinbottoms's Profile: http://forums.slimdevices.com/member.php?userid=255
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

Stuart - if you try the latest 6.5 (today's nightly), you should find
the writePrefs delay is much reduced.  Do you see this?


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

I make the dominant freezes:

writePrefs - 1.3 sec - seen often
Notify: Slim::Player::Playlist::modifyPlaylistCallback
+ Scrobbler and SuperDateTime plugin related
+ web page related ones which this doesn't give enough info for

I think we need to work on these two first (as I see them too).  The
plugin ones need plugin changes...

This leaves the web page ones which need more instrumentation to be
sure what is causing them.  It may be the database lookup, or it may be
something else.  I did try adding instrumentation around the database
calls but took it out as it only had partial coverage.


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[hickinbottoms]

Triode Wrote: 
> Stuart - could you post the whole log (ziped?) Or just a few lines above
> each of these.
> 
> Reason for asking is that we need the lines above the "Response Time >
> 0.5" lines...
> 
> Good news is that we should be able to reduce the ones due to
> "writePrefs" quite easily...

I've attached a gzipped log around the testing I posted earlier. I'm
not sure there's a great deal more in there (aside from the
SuperDateTime refreshes), but it might help.

If you'd like me to switch on more flags just name them and I can redo
this testing. I should have thought of that beforehand, I suppose,
since I expect you'll be interested in HTTP and SQL things in
particular.


+---+
|Filename: messages.1.gz|
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=1315|
+---+

-- 
hickinbottoms

Stuart
-"Never put off until tomorrow what you can put off until the day after
- with Lazy Searching!"-

hickinbottoms's Profile: http://forums.slimdevices.com/member.php?userid=255
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[jonmyatt]

Right I've just switched on perfwarn, not sure which other debug flags I
should be setting though???

This looks bad, is it? 

2006-05-09 09:32:55.1774   Slim::Utils::Prefs::writePrefs
2006-05-09 09:32:55.1782 Response Time > 0.5 : 0.738317012786865
2006-05-09 09:35:25.2366 Start and End node: [contributor:contributor]
2006-05-09 09:35:25.2373 Field query. Need additional join. start and
End node: [contributor:contributor]
2006-05-09 09:35:25.2392 Running SQL query: [SELECT COUNT(DISTINCT
contributors.id) FROM contributor_track, contributors WHERE
contributors.id = contributor_track.contributor  AND (
contributor_track.role IN ( ?, ? ) )]
2006-05-09 09:35:25.2398 Bind arguments: [1, 5]

2006-05-09 09:35:25.2680 Start and End node: [contributor:contributor]
2006-05-09 09:35:25.2687 Field query. Need additional join. start and
End node: [contributor:contributor]
2006-05-09 09:35:25.2706 Running SQL query: [SELECT DISTINCT
contributors.id AS id,contributors.name AS name,contributors.namesort
AS namesort,contributors.moodlogic_id AS
moodlogic_id,contributors.moodlogic_mixable AS
moodlogic_mixable,contributors.musicmagic_mixable AS musicmagic_mixable
FROM contributor_track, contributors WHERE contributors.id =
contributor_track.contributor  AND ( contributor_track.role IN ( ?, ? )
) ORDER BY contributors.namesort]
2006-05-09 09:35:25.2714 Bind arguments: [1, 5]

2006-05-09 09:35:26.3269 Response Time > 0.5 : 1.09503102302551
2006-05-09 09:35:40.4877 Select Task > 0.5 : 15.2736709117889
2006-05-09 09:35:40.4901   Slim::Web::HTTP::processHTTP


i.e. the 15.273 seconds bit... 

Jon.


-- 
jonmyatt

jonmyatt's Profile: http://forums.slimdevices.com/member.php?userid=4124
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Craig wrote:
> Pat - apart from the rescanning, aren't your problems caused by other
> apps using the cpu? whereas these fix's seem to be related to
> SlimServer stalling the streaming.

It could, of course, be anything. But the box is dedicated to being a
SlimServer. It doesn't even have a monitor on it.
I do run Samba on it, so we can easily move ripped files to it,
but its just a slimserver. It has sshd and a few other things, but
nothing of note, zero users ever, no apache, postfix or any
of that stuff.

Its ‎AMD Athlon(tm)  3000+
with a gig of ram.

So, my feeling is that this is the SlimServer failing to keep PCM data
flowing down the wire to the SB1. I could be wrong.
My collection is ~750 CDs, nealy 99% flac.
spread over 4 IDE drives.

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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

Stuart - could you post the whole log (ziped?) Or just a few lines above
each of these.

Reason for asking is that we need the lines above the "Response Time >
0.5" lines...

Good news is that we should be able to reduce the ones due to
"writePrefs" quite easily...


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Andy Grundman]

MOMENTARY PAUSES while SlimScrobbler is submitting (just this once  
- it

didn't happen for any of the other track submits)
2006-05-08 19:45:16.2600 Timer Task > 0.5 : 1.34793710708618
2006-05-08 19:45:16.2616   Plugins::SlimScrobbler::Plugin::submitter
2006-05-08 19:45:16.2631 Response Time > 0.5 : 1.35109996795654
2006-05-08 19:45:17.5286 Timer Task > 0.5 : 0.580141067504883
2006-05-08 19:45:17.5305   Scrobbler::BackgroundHTTP::readHeader
2006-05-08 19:45:17.5325 Response Time > 0.5 : 0.584939002990723


3rd party plugins causing the dropouts can be a real problem, but  
thanks to perfwarn we can find the problem code better. :)


Also, I wonder why this plugin has its own HTTP implementation?   
Maybe it was pre-SimpleAsyncHTTP, but it could be updated to take  
advantage of the new HTTP code.

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[hickinbottoms]

Triode Wrote: 
> To add the the post from Andy above - I would be interested in the
> output from the --perfwarn option added to last night's 6.5 from anyone
> having problems streaming to SB1.  This may help target the problem
> areas in the current server architecture.

To add my data to this I've been running with perfwarn set to 0.5 for
an hour or so and been heavily using the web interface to try to
provoke problems. Extracts from the log showing the warnings are are
below.

Initial web interface display (not playing)
2006-05-08 19:40:54.3443 Response Time > 0.5 : 4.41643714904785
2006-05-08 19:40:54.3753 Select Task > 0.5 : 4.95871186256409
2006-05-08 19:40:54.3950   Slim::Web::HTTP::processHTTP

During a search-as-you-type in default skin (not playing)
2006-05-08 19:41:23.6623 Timer Task > 0.5 : 1.62203288078308
2006-05-08 19:41:23.6639   Slim::Utils::Prefs::writePrefs
2006-05-08 19:41:23.6653 Response Time > 0.5 : 1.62518000602722
2006-05-08 19:41:43.3703 Select Task > 0.5 : 0.746092081069946
2006-05-08 19:41:43.3722   Slim::Web::HTTP::processHTTP
2006-05-08 19:41:43.3781 Response Time > 0.5 : 0.729049921035767
2006-05-08 19:41:45.7676 Select Task > 0.5 : 1.12858891487122
2006-05-08 19:41:45.7692   Slim::Web::HTTP::processHTTP
2006-05-08 19:41:45.7754 Response Time > 0.5 : 1.11205697059631
2006-05-08 19:41:46.9933 Select Task > 0.5 : 1.21611595153809
2006-05-08 19:41:46.9950   Slim::Web::HTTP::processHTTP
2006-05-08 19:41:47.0010 Response Time > 0.5 : 1.19357395172119

Choosing to play a whole artist through web interface (shuffled)
2006-05-08 19:42:27.9961 Response Time > 0.5 : 1.43811297416687
2006-05-08 19:42:28.6246 Request Task > 0.5 : 2.03439784049988
2006-05-08 19:42:28.6261   Execute:
Slim::Control::Commands::playlistXtracksCommand
2006-05-08 19:42:28.6274 Select Task > 0.5 : 2.06929302215576
2006-05-08 19:42:28.6289   Slim::Web::HTTP::processHTTP
2006-05-08 19:42:29.8654 Request Task > 0.5 : 1.23459506034851
2006-05-08 19:42:29.8671   Notify:
Slim::Player::Playlist::modifyPlaylistCallback
2006-05-08 19:42:29.9127 Response Time > 0.5 : 1.29472398757935

Web interface refresh (playing)
2006-05-08 19:42:30.4384 Response Time > 0.5 : 0.523973941802979
2006-05-08 19:42:32.9529 Select Task > 0.5 : 1.67090916633606
2006-05-08 19:42:32.9547   Slim::Web::HTTP::processHTTP
2006-05-08 19:42:55.9541 Timer Task > 0.5 : 1.39309906959534
2006-05-08 19:42:55.9561   Slim::Utils::Prefs::writePrefs
2006-05-08 19:42:55.9578 Response Time > 0.5 : 1.39702200889587
2006-05-08 19:43:03.3812 Select Task > 0.5 : 0.849715948104858
2006-05-08 19:43:03.3828   Slim::Web::HTTP::processHTTP
(and similar messages on each refresh)

Browse artists through web interface (playing)
2006-05-08 19:44:05.6168 Select Task > 0.5 : 0.648431062698364
2006-05-08 19:44:05.6184   Slim::Web::HTTP::processHTTP
2006-05-08 19:44:10.9139 Select Task > 0.5 : 2.03688788414001
2006-05-08 19:44:10.9160   Slim::Web::HTTP::processHTTP
(similar messages when paging through artist letters on web interface)

MOMENTARY PAUSES while SlimScrobbler is submitting (just this once - it
didn't happen for any of the other track submits)
2006-05-08 19:45:16.2600 Timer Task > 0.5 : 1.34793710708618
2006-05-08 19:45:16.2616   Plugins::SlimScrobbler::Plugin::submitter
2006-05-08 19:45:16.2631 Response Time > 0.5 : 1.35109996795654
2006-05-08 19:45:17.5286 Timer Task > 0.5 : 0.580141067504883
2006-05-08 19:45:17.5305   Scrobbler::BackgroundHTTP::readHeader
2006-05-08 19:45:17.5325 Response Time > 0.5 : 0.584939002990723

Browse albums (playing)
2006-05-08 19:47:07.7257 Response Time > 0.5 : 1.50812196731567
2006-05-08 19:47:09.4906 Response Time > 0.5 : 0.816848039627075
2006-05-08 19:47:12.8918 Select Task > 0.5 : 6.70858907699585
2006-05-08 19:47:12.8947   Slim::Web::HTTP::processHTTP

MOMENTARY PAUSE when bringing up player settings (playing)
2006-05-08 19:55:14.2120 Response Time > 0.5 : 1.81775689125061
2006-05-08 19:55:14.5177 Select Task > 0.5 : 2.16191005706787
2006-05-08 19:55:14.5253   Slim::Web::HTTP::processHTTP

This is with 6.5b r7337 with Dan's patch for larger socket buffer. With
netstat I can see the Squeezebox socket with a Send-Q of between 32Kb
and 50Kb. I'm not sure that patch is doing anything for me as I backed
it out and the Send-Q seemed about the same - I don't run the server as
root, so perhaps that's the reason the buffer size wasn't changed.

The server is a lowly 460MHz PentiumII running Gentoo Linux, with MySQL
as the database server. I have an SB1(G). The music is all streaming in
PCM (from FLAC) over wireless (I'm pretty sure the wireless isn't
saturating, however, as dropouts do seem related to SlimServer web
interface activity).

To be honest I was working the web interface pretty hard - certainly
harder than I ever would normally - and it only dropped out twice.
Personally, I'm happy with that, so I'm not sure if it's a combination
of the recent changes to the web interface templating, the socket
options, or some other change i

RE: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Christopher Key]

kdf wrote:
>> I've had a bit of a dig, but not found anything that seems to be
>> conclusive. Could you point me in the right direction, as you know
>> what you're looking for.
> 
> http://forums.slimdevices.com/showthread.php?t=15613
> http://forums.slimdevices.com/showthread.php?t=1166
> http://forums.slimdevices.com/showthread.php?t=21984
> http://forums.slimdevices.com/showthread.php?t=14453
> http://forums.slimdevices.com/showthread.php?t=1348
> 
> and some of these refer to other threads that I haven't bothered to
> dig up. 
> 
> If I've missed anything, I'm sure those involved would be more than
> happy to reiterate or contradict their previous statements.
> 

Can I assume that the position is approximately as follows.  It is agreed
the splitting things up is certainly worthwhile, but that pre Perl 5.8, it
really isn't practical, and requiring Perl 5.8 wasn't acceptable.  Perl 5.8
introduced suitable threading, and the split-scanner is based upon this.
The intention for version 7 is to move over to apache / mod_perl, which will
make threading far easier.

My view is that it would be nice to have multiple threads each serving
requests seperately.  I would envisage having one thread per connected
squeezebox.  SlimServer would create a suitable sized pool of such threads
when it started, and each would be allocated a squeezebox to serve as they
connected.  This way, the user interface would always feel responsive, and
would hopefully prevent stuttery scrolling, poor time display etc.  Any code
that does something slow would only block the user interface actually
calling that code, and would leave other users unaffected.  The option of
whether to update this code to work asynchronously could then be made based
upon whether blocking, and the time delay was acceptable, rather than having
to ensure that no code ever ran for an unnacceptable time.  One could for
example choose to dispatch a thread to perform the database lookups on track
listings, whilst allowing the user to cancel before the lookup completed.

Similarly, the web interface would have a pool of threads, each serving
requests, as would the CLI.  Finally, there would be a low priority thread
resposible for maintaining the database and keeping it up to date, and
scanning as required.  As an aside, it struck me that it might be quite nice
to have the scanner build up a completely new database content during a
rescan.  Only when the rescan completed would the new content be used, so
that performing a rescan could be done slowly with very low priority,
without affecting the user too much.

The model above is I believe how most servers operate, certainly Apache,
MySQL etc, and seems quite sensible.  From what I've understood of the Perl
threading system, this isn't too hard to implement, although converting
SlimServer would be very much tougher.

I've tried to do some research on how Apache / mod_perl work, and it looks
like this solution would effectively implement what is detailed above.
Apache would create threads to deal with each SlimProto connection request,
and would obviously do the same with web requests.  I presume that it would
also be possible / desirable to have apache create a separate thread to
serve each stream request.

Chris Key


___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Andy Grundman]

2006-05-08 20:32:19.7901   Slim::Web::HTTP::processHTTP
2006-05-08 20:32:23.1430 Select Task > 0.5 : 4.31901407241821


This one is not actually a problem as the "Response Time" has not
exceeded the threshold.  It means the task is doing some tricks to
stream audio while it is running, i.e. the task runs for longer than
the threshold, but the response time does not.


Right.  There are 2 reasons processHTTP could take a long time:

1. Long time to render templates.  This situation is handled by  
calling idleStreams during each template's processing phase so should  
not cause problems.


2. Long database queries (Browse Albums, etc).  This cannot currently  
be worked around and will cause dropouts.  Once we get to split- 
scanner if we still have DB performance issues we can revisit.  I  
also worry about people with low-end CPUs such as NAS boxes.


___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

Thanks - for info:

Craig Wrote: 
> 2006-05-08 20:29:20.4101 Request Task > 0.5 : 8.02541708946228
> 2006-05-08 20:29:20.4106   Notify:
> Plugins::RandomPlay::Plugin::commandCallback
> 2006-05-08 20:29:20.4118 Response Time > 0.5 : 8.05730199813843
> 
This one is a problem and as Dan says should be addressed in
split-scanner

> 
> 2006-05-08 20:32:19.7901   Slim::Web::HTTP::processHTTP
> 2006-05-08 20:32:23.1430 Select Task > 0.5 : 4.31901407241821
> 
This one is not actually a problem as the "Response Time" has not
exceeded the threshold.  It means the task is doing some tricks to
stream audio while it is running, i.e. the task runs for longer than
the threshold, but the response time does not.


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

Triode,

The main ones I'm seeing are

2006-05-08 20:29:20.4101 Request Task > 0.5 : 8.02541708946228
2006-05-08 20:29:20.4106   Notify:
Plugins::RandomPlay::Plugin::commandCallback
2006-05-08 20:29:20.4118 Response Time > 0.5 : 8.05730199813843

Which Dan said has been dealt with in the split scanner branch and

2006-05-08 20:32:19.7901   Slim::Web::HTTP::processHTTP
2006-05-08 20:32:23.1430 Select Task > 0.5 : 4.31901407241821

Hope this helps

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

To add the the post from Andy above - I would be interested in the
output from the --perfwarn option added to last night's 6.5 from anyone
having problems streaming to SB1.  This may help target the problem
areas in the current server architecture.

Start the server from the command line with the param --perfwarn=X,
where X is a number between 0.1 and 0.5

X is actually a time in seconds.  With this option enabled, the server
produces warning messages if the main loop inside the server code takes
longer than X seconds to execute.  The critical message is "Response
Time > X".  If this occurs, what appeared just above it?  If serveral
people try this, it may identify a common cause of server delays which
can then be looked at more closely.


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

RE: [SlimDevices: Beta] Re: SB1's struggling to keep up

[kdf]

I've had a bit of a dig, but not found anything that seems to be conclusive.
Could you point me in the right direction, as you know what you're looking
for.


http://forums.slimdevices.com/showthread.php?t=15613
http://forums.slimdevices.com/showthread.php?t=1166
http://forums.slimdevices.com/showthread.php?t=21984
http://forums.slimdevices.com/showthread.php?t=14453
http://forums.slimdevices.com/showthread.php?t=1348

and some of these refer to other threads that I haven't bothered to dig up.

If I've missed anything, I'm sure those involved would be more than  
happy to reiterate or contradict their previous statements.


-kdf
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

RE: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Christopher Key]

kdf wrote:
> this has been covered before.  feel free to search, to avoid going
> through the same exact discussion again :)
> ___ beta mailing list
> beta@lists.slimdevices.com
> http://lists.slimdevices.com/lists/listinfo/beta 

I've had a bit of a dig, but not found anything that seems to be conclusive.
Could you point me in the right direction, as you know what you're looking
for.

Chris

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

I can view any page except view artwork without pausing on a 10,500 song
DB so that's a definate improvement.

Pat - apart from the rescanning, aren't your problems caused by other
apps using the cpu? whereas these fix's seem to be related to
SlimServer stalling the streaming.

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

Robin Bowes Wrote: 
> ron thigpen wrote:
> > Craig wrote:
> > 
> >> I'm still getting pauses when Random Mix makes a new selection but
> I've
> >> tracked this to DBI:Find and I guess this will be covered by the
> move to
> >> mySQL?.
> > 
> > This glitch is also apparent on my SB2s.  It really messes up any
> > attempt to use Random Mix with two boxes sync'd.
> > 
> > Do you know if there is a bug filed for the specific issue with
> > DBI:Find?  There might be code optimizations that could resolve this
> > independently or in concert with the mySQL migration.
> 
> I too saw this when attempting to run slimserver on my SO's laptop
> (1GHz
> P3 with 256MB RAM running Windows XP).
> 
> It runs much better on a Compaq iPaq box with a 733MHz P3 and 512MB
> RAM
> running Fedora Core 5.
> 
> R.

I've actually tracked the delay down to one particular line in DBI:Find
but the line is exactly the same in 6.2 and that executes in no time.
I'm afraid that i'm out of my depth after that.

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Robin Bowes]

ron thigpen wrote:
> Craig wrote:
> 
>> I'm still getting pauses when Random Mix makes a new selection but I've
>> tracked this to DBI:Find and I guess this will be covered by the move to
>> mySQL?.
> 
> This glitch is also apparent on my SB2s.  It really messes up any
> attempt to use Random Mix with two boxes sync'd.
> 
> Do you know if there is a bug filed for the specific issue with
> DBI:Find?  There might be code optimizations that could resolve this
> independently or in concert with the mySQL migration.

I too saw this when attempting to run slimserver on my SO's laptop (1GHz
P3 with 256MB RAM running Windows XP).

It runs much better on a Compaq iPaq box with a 733MHz P3 and 512MB RAM
running Fedora Core 5.

R.

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[ron thigpen]

Craig wrote:


I'm still getting pauses when Random Mix makes a new selection but I've
tracked this to DBI:Find and I guess this will be covered by the move to
mySQL?.


This glitch is also apparent on my SB2s.  It really messes up any 
attempt to use Random Mix with two boxes sync'd.


Do you know if there is a bug filed for the specific issue with 
DBI:Find?  There might be code optimizations that could resolve this 
independently or in concert with the mySQL migration.


--rt
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[andyg]

OK, right.  Those heavy database pages are still a problem I'm not sure
we'll be able to solve until we get DBIx::Class merged in from
split-scanner.


-- 
andyg

andyg's Profile: http://forums.slimdevices.com/member.php?userid=3292
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

andyg wrote:
> Do those dropouts only occur during a rescan?  Try setting the new
> perfwarn option.  You'll need the latest nightly for this.

Not for me, they occur during normal playback.

Or, they also occur during normal playback. During rescan,
my server is unlistenable. Its only a AMD2400+ or so with a gig of ram


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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[jonmyatt]

andyg Wrote: 
> Do those dropouts only occur during a rescan?  Try setting the new
> perfwarn option.  You'll need the latest nightly for this.
> 
> ./slimserver.pl --perfwarn=0.5

OK ta - will grab it now and try. And no, they occur when the web
interface has a lot to do - e.g. Browse Artists. 

Jon.


-- 
jonmyatt

jonmyatt's Profile: http://forums.slimdevices.com/member.php?userid=4124
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[andyg]

Do those dropouts only occur during a rescan?  Try setting the new
perfwarn option.  You'll need the latest nightly for this.

./slimserver.pl --perfwarn=0.5


-- 
andyg

andyg's Profile: http://forums.slimdevices.com/member.php?userid=3292
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[jonmyatt]

Dan Sully Wrote: 
> 
> FYI - here's a better patch which checks the size of the sndbuf first.
> 

Doesn't seem to have improved matters here, I'm still getting dropouts
caused by the server process hogging CPU. This is with 6.5b1 build
7296, and a library of 6000-ish songs. 

Which debug flags should I be setting to further investigate the
cause[s] of this?

Thanks,

Jon.


-- 
jonmyatt

jonmyatt's Profile: http://forums.slimdevices.com/member.php?userid=4124
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

I've just installed the 5/8 build of 6.5 windows and I seem to be able
to do anything with the web browser with only small dips in buffer
fullness as opposed to the pauses I was getting before :-)

I'm still getting pauses when Random Mix makes a new selection but I've
tracked this to DBI:Find and I guess this will be covered by the move to
mySQL?.

Thanks for all your efforts in this.

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

Triode Wrote: 
> 
> Are you willing to try 6.5 as I am about to put some more diagnostics
> in this to help understand what causes long response times.

I can give it a go on windows if you tell me what to do.

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

You could try increasing it to MAXCHUNKSIZE * 3.  [don't think the
kernel will support it going much bigger though]

I'm assuming you are streaming as raw pcm.  In this case (32K * 3) is
about 0.5 seconds of additional buffering.  Hence it should aborb small
server delays.  What we need to do is find the cause of the server
taking a long time to run.

Are you willing to try 6.5 as I am about to put some more diagnostics
in this to help understand what causes long response times.


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Pat Farrell wrote:
>>Triode wrote:
>>>you may want to try the following small edit:
>>> setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE * 2;
> So far, I've listened to four or five CDs end to end,
> and not noticed any dropouts. A small sample, but this has potential.

Upon further review
Not good. Still get dropouts.

Since it was not trivially reproducible before, I'm not
sure that I can tell that it is better or not.

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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Pat Farrell wrote:
> Triode wrote:
>>you may want to try the following small edit:
>>  setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE * 2;
>>
> Let me listen a bit and I'll let you know.

So far, I've listened to four or five CDs end to end,
and not noticed any dropouts. A small sample, but this has potential.


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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Dan Sully]

* Dan Sully shaped the electrons to say...


FYI - here's a better patch which checks the size of the sndbuf first.


Oops. Let's try that again.

-D
--
 you know, most free operating systems come preinstalled with their own 
high horse.
=== Slim/Web/HTTP.pm
==
--- Slim/Web/HTTP.pm(revision 12581)
+++ Slim/Web/HTTP.pm(local)
@@ -1276,9 +1276,16 @@
 
push @{$outbuf{$httpClient}}, \%segment;
 
-#   May want to enable this later, if we find that that it has any effect on 
some platforms...
-#  setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE;
-   
+   # Set the kernel's send buffer to be higher so that there is less
+   # chance of audio skipping if/when we block elsewhere in the code.
+   # 
+   # Check to make sure that our target size isn't smaller than the
+   # kernel's default size.
+   if (unpack('I', getsockopt($httpClient, SOL_SOCKET, SO_SNDBUF)) < 
(MAXCHUNKSIZE * 2)) {
+
+   setsockopt($httpClient, SOL_SOCKET, SO_SNDBUF, (MAXCHUNKSIZE * 
2));
+   }
+
Slim::Networking::Select::addWrite($httpClient, 
\&sendStreamingResponse);
 
# we aren't going to read from this socket anymore so don't select on 
it...
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Dan Sully]

* Triode shaped the electrons to say...


Find the line:
#   setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE;

and replace with:
setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE * 2;

This won't make the server go any faster, but does seem to make use of
a larger tcp buffer in linux 2.6


FYI - here's a better patch which checks the size of the sndbuf first.

=== Slim/Web/HTTP.pm
==
--- Slim/Web/HTTP.pm(revision 12581)
+++ Slim/Web/HTTP.pm(local)
@@ -1276,9 +1276,16 @@

push @{$outbuf{$httpClient}}, \%segment;

-#   May want to enable this later, if we find that that it has any effect on 
some platforms...
-#  setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE;
-   
+   # Set the kernel's send buffer to be higher so that there is less
+   # chance of audio skipping if/when we block elsewhere in the code.
+	# 
+	# Check to make sure that our target size isn't smaller than the

+   # kernel's default size.
+   if (unpack('I', getsockopt($httpClient, SOL_SOCKET, SO_SNDBUF)) < 
MAXCHUNKSIZE) {
+
+   setsockopt($httpClient, SOL_SOCKET, SO_SNDBUF, (MAXCHUNKSIZE * 
2));
+   }
+
Slim::Networking::Select::addWrite($httpClient, 
\&sendStreamingResponse);

# we aren't going to read from this socket anymore so don't select on 
it...

-D
--
 you know, most free operating systems come preinstalled with their own 
high horse.
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Pat Farrell]

Triode wrote:

> 
> Given then I know you are on linux,

You bet.
Linux beatles.pfarrell.com 2.6.8.1-12mdk #1 Fri Oct 1 12:53:41 CEST 2004
i686 AMD Athlon(tm)  3000+ unknown GNU/Linux


> you may want to try the following small edit:
>   setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE * 2;
> 
> This won't make the server go any faster, but does seem to make use of
> a larger tcp buffer in linux 2.6

Done.
Let me listen a bit and I'll let you know.

Thanks
Pat

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

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[nmizel]

Well, I also suffered from dropouts with my SB1 wired and SlimServer
running on a really slim server (VIA EPIA 5000 @ 533MHz,  2 250GB
external USB 1.1 drives).

The solution I found at that time (and which I still use) was to run 2
simultaneous SlimServers on different ports, one for the music
streaming and the other for the web UI and scanning, and to access the
web UI through an Apache proxy to redirect the requests to the proper
server ('play' requests to the main server and searches and web UI
browsing to the other). This was pretty hairy to set up, full Apache
configuration below.

Since then I never experienced any dropout anymore, even when listening
flac, searching for a song through the web UI (I currently have over
15'000 tracks) and rescanning my music collection at the same time.

This is how it looks like, happy reading.

Nicolas


[EMAIL PROTECTED] ~]# ps -ef | grep slimserver
503  10976 1  2 01:53 ?00:32:43 slimserver
503  10978 1  0 01:53 ?00:00:00
/usr/local/slimserver/Bin/i386-linux/mDNSResponderPosix -d -f
/usr/local/slimserver/mDNS.conf -P /usr/local/slimserver/mDNS.pid
503  11009 1  0 01:53 ?00:01:47 slimserver
503   9394 1  7 23:04 ?00:00:05
/usr/local/slimserver/Bin/i386-linux/flac -dcs --force-raw-format
--endian=little --sign=signed --skip=0 --until=-0 -- /music/usb1/Alain
Bashung/Osez Josephine/06.flac
root  9500  9466  0 23:05 pts/000:00:00 grep slimserver

[EMAIL PROTECTED] ~]# netstat -alnp | grep slimserver
tcp0  0 0.0.0.0:90900.0.0.0:*  
LISTEN  10976/slimserver
tcp0  0 0.0.0.0:90000.0.0.0:*  
LISTEN  10976/slimserver
tcp0  0 0.0.0.0:90010.0.0.0:*  
LISTEN  11009/slimserver
tcp0  0 0.0.0.0:34830.0.0.0:*  
LISTEN  10976/slimserver
tcp0568 192.168.1.2:3483192.168.1.3:36684  
ESTABLISHED 10976/slimserver
tcp0  0 127.0.0.1:9090  127.0.0.1:34515
ESTABLISHED 10976/slimserver
tcp0  21900 192.168.1.2:9000192.168.1.3:36700  
ESTABLISHED 10976/slimserver
udp0  0 0.0.0.0:34830.0.0.0:*  
10976/slimserver
unix  3  [ ] STREAM CONNECTED 2761469
11009/slimserver
unix  3  [ ] STREAM CONNECTED 2761457
10976/slimserver

[EMAIL PROTECTED] init.d]# cat /etc/init.d/slimserver
...
SLIMSERVER_BIN="$SLIMSERVER_HOME/slimserver.pl"
SLIMSERVER1_BIN="$SLIMSERVER_HOME/slimserver1.pl"

[ -x $SLIMSERVER_BIN -a -f $SLIMSERVER_CFG ] || exit 5

start() {
echo -n "Starting SlimServer (9000): "
daemon --user $SLIMSERVER_USER $SLIMSERVER_BIN $SLIMSERVER_ARGS
--httpport 9000 --cliport 9090
echo
echo -n "Starting SlimServer (9001): "
daemon --user $SLIMSERVER_USER $SLIMSERVER1_BIN
$SLIMSERVER_ARGS --httpport 9001 --cliport 0
--logfile=${SLIMSERVER_LOG%.log}1.log
...

[EMAIL PROTECTED] mizel_ch.d]# cat slimserver_proxy.conf

LoadFile /usr/lib/libxml2.so
LoadModule proxy_html_module modules/mod_proxy_html.so


# slimserver.pl listening on port 9000

RewriteEngine on
RewriteBase /slimserver
RewriteRule (.*)(player=)$ $1$200:04:20:05:75:b2
RewriteCond %{QUERY_STRING} !^hierarchy=playlist
RewriteRule :9000(.*/browsedb\.html.*) /slimserver1$1 [L]
RewriteRule :9000(.*/browsetree\.html.*) /slimserver1$1 [L]
RewriteRule :9000(.*/search\.html.*) /slimserver1$1 [L]
RewriteCond %{QUERY_STRING} !action=
RewriteRule :9000(.*/ShoutcastBrowser/index\.html.*)
/slimserver1$1 [L]
RewriteRule :9000(.*/Picks/index\.html\?player=.*)
/slimserver1$1 [L]
RewriteRule :9000(.*/RadioIO/index\.html\?player=.*)
/slimserver1$1 [L]
RewriteRule :9000(.*/livesearch\.(?:html|xml).*) /slimserver1$1
[L]
RewriteRule :9000(.*/advanced_search\.html.*) /slimserver1$1
[L]
RewriteRule :9000(.*/songinfo\.html.*) /slimserver1$1 [L]
RewriteRule :9000(.*/setup\.html\?.*rescan.*) /slimserver1$1
[L]
RewriteRule :9000(.*/.*\.jpg.*) /slimserver1$1 [L]
RequestHeader set Referer http://localhost:9000/
ProxyPass http://localhost:9000/
ProxyPassReverse http://localhost:9000/
SetOutputFilter proxy-html
ProxyHTMLURLMap / /slimserver/


# slimserver1.pl listening on port 9001

RequestHeader set Referer http://localhost:9001/
ProxyPass http://localhost:9001/
ProxyPassReverse http://localhost:9001/
SetOutputFilter proxy-html
ProxyHTMLURLMap / /slimserver/



SetOutputFilter proxy-html;DEFLATE
ProxyHTMLURLMap / /slimserver/
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
dont-vary 



SetOutputFilter proxy-html;DEFLATE
ProxyHTMLURLMap / /slimserver/
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
dont-vary 



SetOutputFilter proxy-html;DEFLATE
ProxyHTMLURLMap / /slimserver/
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
dont-vary 



SetOutputFilter proxy-html;DEFLATE
ProxyHTMLURLMap / /slimserver/
SetEnvIfN

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

Pat,

Given then I know you are on linux, you may want to try the following
small edit:
In Slim/Web/HTTP.pm

Find the line:
#   setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE;

and replace with:
setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE * 2;

This won't make the server go any faster, but does seem to make use of
a larger tcp buffer in linux 2.6

Does it help?

Adrian


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[coldslabs]

pfarrell Wrote: 
> Craig wrote:
> > I'm seeing more and more problems with pausing on SB1's using flac
> and
> > 6.5
> 
> I have been seeing dropouts on my SB1 (wired) ever since I started
> using the 6.x series servers.
> 
> I am sure that I entered an issue into bugzilla on it long ago,
> but I just checked and can't find any by me at all,
> and not a lot of other issues on the topic.
> 
> While I'd love to have some SB2/3, I've got SB1
> 

Then I'm not the only one! I have the same problem (pauses and stops
using a wired SB1). I've been trying to troubleshoot this problem
assuming something is wrong. It has been a long process:

"coldslabs" is my user name. My part starts on page 3 of this thread:

http://forums.slimdevices.com/showthread.php?t=20783&page=3


-- 
coldslabs

coldslabs's Profile: http://forums.slimdevices.com/member.php?userid=450
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[jonmyatt]

andyg Wrote: 
> 
> I assume you guys are using 6.5 nightlies or trunk?  I just committed 
> 
> a patch that implements idleStreams during template processing.  I'm  
> testing on an SB1 streaming FLAC and can reload the main web  
> interface repeatedly without any dropouts.  Please test on your  
> systems and see if you notice any improvement.

Yeah I'm on a 6.5 nightly from a few days ago. I'll grab the latest
when I get a chance and report back. It probably won't be until Sunday
or Monday now.

Jon.


-- 
jonmyatt

jonmyatt's Profile: http://forums.slimdevices.com/member.php?userid=4124
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

While we're on this, but considering the current architecture - I was
wondering whether we really want idleStreams to handle all sockets on
the select vectors.  This increases the chance of handling a new web
page in the middle of processing another.  Would a reduced set for
idleStreams be approriate (easy option being just the write vector? but
ideally just the streaming ones?)


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

RE: [SlimDevices: Beta] Re: SB1's struggling to keep up

[kdf]

this has been covered before.  feel free to search, to avoid going  
through the same exact discussion again :)

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

RE: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Christopher Key]

hickinbottoms wrote:
> cjk32 Wrote:
>> It would be nice to be able to run the thread serving audio data with
>> a high priority, the web interface at normal, and the scanner at low
>> priority. It'd certainly be of use to people like me who don't run
>> slimserver on a dedicated server.
> 
> I'm not even sure that's necessary. I see this as well (to the extent
> I avoid the web interface altogether while playing, which is a
> shame), and I suspect the stalls are simply because the main
> application thread (which also currently streams audio to the
> players) is taking too long between each fill operation.
> 
> I suspect that's as much IO wait time as pure CPU hogging - eg if the
> database is thrashing the disk doing a search then the CPU probably
> won't be maxed out, but because of the architecture that spare CPU
> time won't be used to fill the players.   
> 
> Filling the players is actually a very low-CPU-use activity (even
> with transcoding it takes surprising little CPU to stream over the
> network). I wouldn't be surprised if simply breaking out the player
> streaming to another thread/process would solve this problem without
> having to mess around with priorities at all.
> 
> I've personally looked around to try to increase the socket buffer
> size within the server to try to compensate as I'm convinced that the
> stuttering I get is because of the server not filling the server-side
> socket quick enough, rather than because the network bandwidth has
> become exhausted. Given that it takes almost no CPU to then get that
> data over the network I was hoping this would effectively extend the
> SB1's limited buffer. I didn't have any joy with that approach,
> though.   
> 
> I'd therefore also prefer the streaming to be split off rather than
> the scanning - after all most of the performance problems reported
> are because audio stutters during scanning, not that the web
> interface is sluggish. However, I know the Slim Devices developers
> have looked into it quite a bit more than I have so they may have
> much better evidence than my simple gut feel as to why the current
> development is the right one.  
> 
> I suspect such an architectural change would become easier once the
> main pain of moving the scanning out has been taken, because that
> will already have proved a multi-process architecture that shares
> access to the database successfully. Once that's done it doesn't
> sound too complex to have a small separate process/thread that reads
> the top of the playlist from the database and streams that out (with
> any transcoding necessary).  
> 
> Does anyone know of a bug for this in Bugzilla? If not it might be
> worth creating one so that it could be voted for. 

I'm (fortunately) not suffering dropouts --- am I right in thinking that the
SB2/3 have larger internal buffers?  The main issue is that slimserver does
seem to make the computer generally less responsive, regardless of whether
it's actually streaming at the time.  It would hence be nice to be able to
have the time critical bits running with a high priority, making the system
nice and responsive, and to have the CPU intensive, less time critical bits
running with a lower priority so as not to interfere with normal computer
usage.  I presume that as the effort is going into splitting off the
scanning, that that's where most of the CPU is going, and that once that's
done, the occasional CPU hogging will cease.  Nevertheless, it does seem to
make sense to split off the streaming so that one doesn't have to worry too
much about slower tasks elsewhere.

I don't really know what involved in the following, but I'd be interested to
hear some opinions on whether there's any merit in splitting things up
somewhat more, having threads for:  Streaming; The web interface; Scanning;
Each connected client.  This would mean that any slow operations, whilst
potentially taking a while to return, would not grossly affect other users.
Even with a relatively small music collection, some operations are fairly
slow to respond, with delays of up to a few seconds.  This isn't a problem
with one squeezebox, but with several, I can imagine it could get really
quite annoying to have the display freeze whenever another user was doing
something slow.

Chris Key

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Triode]

You should also be able to see the performance improvement from this on
the "Server Response Time" graph in the Health plugin.  

This should also give an indication if the server is taking a long time
to spin back to select which is causing SB1 dropouts.  I'd be interested
to see what is says in your problem cases.


-- 
Triode

Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[hickinbottoms]

andyg Wrote: 
> I assume you guys are using 6.5 nightlies or trunk?  I just committed  
> a patch that implements idleStreams during template processing.  I'm  
> testing on an SB1 streaming FLAC and can reload the main web  
> interface repeatedly without any dropouts.  Please test on your  
> systems and see if you notice any improvement.

That was good timing! I am running 6.5 - I'll give that a whirl and see
what happens.


-- 
hickinbottoms

Stuart
-"Never put off until tomorrow what you can put off until the day after
- with Lazy Searching!"-

hickinbottoms's Profile: http://forums.slimdevices.com/member.php?userid=255
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Andy Grundman]

On May 5, 2006, at 12:12 PM, Andy Grundman wrote:



On May 5, 2006, at 11:53 AM, jonmyatt wrote:



hickinbottoms Wrote:
I'd therefore also prefer the streaming to be split off rather  
than the

scanning - after all most of the performance problems reported are
because audio stutters during scanning, not that the web  
interface is

sluggish.


Hmmm, at the risk of sounding churlish, for me it's actually both.  
The
web interface is nowhere like as responsive as I feel it should  
be. But

whilst it's annoying, that's something I can live with - the music
pausing is what really drives me nuts.


I assume you guys are using 6.5 nightlies or trunk?  I just  
committed a patch that implements idleStreams during template  
processing.  I'm testing on an SB1 streaming FLAC and can reload  
the main web interface repeatedly without any dropouts.  Please  
test on your systems and see if you notice any improvement.




I moved this from my test server to my real slimserver, and I still  
get dropouts when hitting a database-intensive page such as "Browse  
Albums". :(  This is clearly DBI blocking everything.




___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Andy Grundman]

On May 5, 2006, at 11:53 AM, jonmyatt wrote:



hickinbottoms Wrote:
I'd therefore also prefer the streaming to be split off rather  
than the

scanning - after all most of the performance problems reported are
because audio stutters during scanning, not that the web interface is
sluggish.


Hmmm, at the risk of sounding churlish, for me it's actually both. The
web interface is nowhere like as responsive as I feel it should be.  
But

whilst it's annoying, that's something I can live with - the music
pausing is what really drives me nuts.


I assume you guys are using 6.5 nightlies or trunk?  I just committed  
a patch that implements idleStreams during template processing.  I'm  
testing on an SB1 streaming FLAC and can reload the main web  
interface repeatedly without any dropouts.  Please test on your  
systems and see if you notice any improvement.


___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[jonmyatt]

hickinbottoms Wrote: 
> I'd therefore also prefer the streaming to be split off rather than the
> scanning - after all most of the performance problems reported are
> because audio stutters during scanning, not that the web interface is
> sluggish.

Hmmm, at the risk of sounding churlish, for me it's actually both. The
web interface is nowhere like as responsive as I feel it should be. But
whilst it's annoying, that's something I can live with - the music
pausing is what really drives me nuts.

Jon.


-- 
jonmyatt

jonmyatt's Profile: http://forums.slimdevices.com/member.php?userid=4124
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[hickinbottoms]

Craig Wrote: 
> Just as an aside, I can't download the lazysearch zips from the trac
> site, they show as corrupt!

Oh dear, that's not right. They work for me when I've just tried it
(opening the archive with either WinZip or 7-Zip on Windows, downloaded
with Firefox).

Can you try the following direct links? Report back problems either in
the 3rd party plugins or through a PM to save polluting this thread,
though.

V1.0:
http://tinyurl.com/jbxeu

V2.0:
http://tinyurl.com/hzlms


-- 
hickinbottoms

Stuart
-"Never put off until tomorrow what you can put off until the day after
- with Lazy Searching!"-

hickinbottoms's Profile: http://forums.slimdevices.com/member.php?userid=255
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

Stuart,

Just as an aside, I can't download the lazysearch zips from the trac
site, they show as corrupt!

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[hickinbottoms]

cjk32 Wrote: 
> It would be nice to be able to run the thread serving audio data with a
> high priority, the web interface at normal, and the scanner at low
> priority.
> It'd certainly be of use to people like me who don't run slimserver on
> a dedicated server.

I'm not even sure that's necessary. I see this as well (to the extent I
avoid the web interface altogether while playing, which is a shame), and
I suspect the stalls are simply because the main application thread
(which also currently streams audio to the players) is taking too long
between each fill operation.

I suspect that's as much IO wait time as pure CPU hogging - eg if the
database is thrashing the disk doing a search then the CPU probably
won't be maxed out, but because of the architecture that spare CPU time
won't be used to fill the players.

Filling the players is actually a very low-CPU-use activity (even with
transcoding it takes surprising little CPU to stream over the network).
I wouldn't be surprised if simply breaking out the player streaming to
another thread/process would solve this problem without having to mess
around with priorities at all.

I've personally looked around to try to increase the socket buffer size
within the server to try to compensate as I'm convinced that the
stuttering I get is because of the server not filling the server-side
socket quick enough, rather than because the network bandwidth has
become exhausted. Given that it takes almost no CPU to then get that
data over the network I was hoping this would effectively extend the
SB1's limited buffer. I didn't have any joy with that approach,
though.

I'd therefore also prefer the streaming to be split off rather than the
scanning - after all most of the performance problems reported are
because audio stutters during scanning, not that the web interface is
sluggish. However, I know the Slim Devices developers have looked into
it quite a bit more than I have so they may have much better evidence
than my simple gut feel as to why the current development is the right
one.

I suspect such an architectural change would become easier once the
main pain of moving the scanning out has been taken, because that will
already have proved a multi-process architecture that shares access to
the database successfully. Once that's done it doesn't sound too
complex to have a small separate process/thread that reads the top of
the playlist from the database and streams that out (with any
transcoding necessary).

Does anyone know of a bug for this in Bugzilla? If not it might be
worth creating one so that it could be voted for.


-- 
hickinbottoms

Stuart
-"Never put off until tomorrow what you can put off until the day after
- with Lazy Searching!"-

hickinbottoms's Profile: http://forums.slimdevices.com/member.php?userid=255
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[jonmyatt]

Hmm, I'm already using MySQL - didn't seem to fix it for me.


-- 
jonmyatt

jonmyatt's Profile: http://forums.slimdevices.com/member.php?userid=4124
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

andyg Wrote: 
> 
> Yeah, audio data should be the top priority.  I was just throwing out 
> 
> some ideas. :)

That's ok, I didn't understand half of what you said anyway :)

I Just thought I'd bring it up because as 6.5 develops I can see it
happening more and more and I guess that SB1's will be in the minority
soon.

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

RE: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Christopher Key]

Andy Grundman wrote:
> On May 5, 2006, at 10:32 AM, Craig wrote:
> 
>> 
>> Thanks Andy,
>> 
>> I'm looking forward to the move to mySQL but wouldn't it make more
>> sense to make the streaming more resilient rather than trying to fix
>> everything that could stop it?
> 
> Yeah, audio data should be the top priority.  I was just throwing out
> some ideas. :)

It would be nice to be able to run the thread serving audio data with a high
priority, the web interface at normal, and the scanner at low priority.
It'd certainly be of use to people like me who don't run slimserver on a
dedicated server.

Chris Key

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Andy Grundman]

On May 5, 2006, at 10:32 AM, Craig wrote:



Thanks Andy,

I'm looking forward to the move to mySQL but wouldn't it make more
sense to make the streaming more resilient rather than trying to fix
everything that could stop it?


Yeah, audio data should be the top priority.  I was just throwing out  
some ideas. :)

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[Craig]

Thanks Andy,

I'm looking forward to the move to mySQL but wouldn't it make more
sense to make the streaming more resilient rather than trying to fix
everything that could stop it?

Craig


-- 
Craig

Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Andy Grundman]

On May 5, 2006, at 9:59 AM, Andy Grundman wrote:



On May 5, 2006, at 9:37 AM, jonmyatt wrote:



I'm seeing this too, gaps in the music drive me mad when using the  
web

interface for anything. I can see slimserver.pl using 99% CPU on my
linux server when this happens.


Processing TT templates can take some time, especially if they are  
complicated and have a lot of loops.  I wonder if we could make our  
TT processing more friendly by using our own Template::Context or  
Template::Document subclass that throws in some calls to  
idleStreams.  These are called once for each template, and since  
most/all of our templates use a lot of wrappers, includes,  
processes, etc, this might help.  Also, slow database queries  
resulting from web requests are also a problem (maybe even a bigger  
problem).  The only way to solve this is to move DBI queries into  
another process so they don't block the main loop, ala POE's EasyDBI.


I should also point out that with the upcoming move to DBIx::Class  
and MySQL we'll see much improved database performance as well. :)

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

Re: [SlimDevices: Beta] Re: SB1's struggling to keep up

[Andy Grundman]

On May 5, 2006, at 9:37 AM, jonmyatt wrote:



I'm seeing this too, gaps in the music drive me mad when using the web
interface for anything. I can see slimserver.pl using 99% CPU on my
linux server when this happens.


Processing TT templates can take some time, especially if they are  
complicated and have a lot of loops.  I wonder if we could make our  
TT processing more friendly by using our own Template::Context or  
Template::Document subclass that throws in some calls to  
idleStreams.  These are called once for each template, and since most/ 
all of our templates use a lot of wrappers, includes, processes, etc,  
this might help.  Also, slow database queries resulting from web  
requests are also a problem (maybe even a bigger problem).  The only  
way to solve this is to move DBI queries into another process so they  
don't block the main loop, ala POE's EasyDBI.


http://search.cpan.org/~abw/Template-Toolkit-2.14/lib/Template/Manual/ 
Internals.pod





___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta

[SlimDevices: Beta] Re: SB1's struggling to keep up

[jonmyatt]

I'm seeing this too, gaps in the music drive me mad when using the web
interface for anything. I can see slimserver.pl using 99% CPU on my
linux server when this happens.

Jon.


-- 
jonmyatt

jonmyatt's Profile: http://forums.slimdevices.com/member.php?userid=4124
View this thread: http://forums.slimdevices.com/showthread.php?t=23641

___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta