Discussion:
SB1's struggling to keep up
Craig
2006-05-05 10:51:00 UTC
Permalink
I'm seeing more and more problems with pausing on SB1's using flac and
6.5

As I see it, it's caused by functions such as browser refreshes
blocking the actual streaming. When using flac the SB1's buffer only
holds around 1 second of music so any operation that lasts longer than
that causes a pause.

I don't see any problems on SB2's or if I limit the bandwidth to the
player.

I know there are plans to move scanning to a seperate thread but what
about 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
jonmyatt
2006-05-05 13:37:54 UTC
Permalink
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
Andy Grundman
2006-05-05 13:59:52 UTC
Permalink
Post by 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.
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
Andy Grundman
2006-05-05 14:12:50 UTC
Permalink
Post by Andy Grundman
Post by 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.
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. :)
Craig
2006-05-05 14:32:06 UTC
Permalink
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
Andy Grundman
2006-05-05 14:47:11 UTC
Permalink
Post by 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?
Yeah, audio data should be the top priority. I was just throwing out
some ideas. :)
Christopher Key
2006-05-05 14:55:00 UTC
Permalink
Post by Andy Grundman
Post by 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?
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
hickinbottoms
2006-05-05 15:27:34 UTC
Permalink
Post by Christopher Key
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
Craig
2006-05-05 15:38:47 UTC
Permalink
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
hickinbottoms
2006-05-05 15:48:25 UTC
Permalink
Post by Craig
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
jonmyatt
2006-05-05 15:53:01 UTC
Permalink
Post by hickinbottoms
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
Andy Grundman
2006-05-05 16:12:11 UTC
Permalink
Post by jonmyatt
Post by hickinbottoms
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.
Andy Grundman
2006-05-05 16:26:00 UTC
Permalink
Post by Andy Grundman
Post by jonmyatt
Post by hickinbottoms
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.
Dan Sully
2006-05-05 16:29:03 UTC
Permalink
* Andy Grundman shaped the electrons to say...
Post by Andy Grundman
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.
Andy - can you try this on the split-scanner branch? Using DBIx::Class, we're
able to do a limit & offset now for the browse pages and still have the alpha
page bar without inflating all the rows in the database.

-D
--
I'm really looking forward to this hangover.
Andy Grundman
2006-05-05 16:29:37 UTC
Permalink
Post by Dan Sully
* Andy Grundman shaped the electrons to say...
Post by Andy Grundman
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.
Andy - can you try this on the split-scanner branch? Using
DBIx::Class, we're
able to do a limit & offset now for the browse pages and still have the alpha
page bar without inflating all the rows in the database.
Yeah that was the next thing I was going to check out.
hickinbottoms
2006-05-05 16:35:08 UTC
Permalink
Post by Andy Grundman
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
Triode
2006-05-05 16:44:07 UTC
Permalink
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
jonmyatt
2006-05-05 18:13:07 UTC
Permalink
Post by Andy Grundman
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
Christopher Key
2006-05-05 17:08:11 UTC
Permalink
Post by hickinbottoms
Post by Christopher Key
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
kdf
2006-05-05 17:17:23 UTC
Permalink
this has been covered before. feel free to search, to avoid going
through the same exact discussion again :)
Christopher Key
2006-05-08 17:21:55 UTC
Permalink
Post by kdf
this has been covered before. feel free to search, to avoid going
through the same exact discussion again :)
_______________________________________________ beta mailing list
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
kdf
2006-05-08 17:35:32 UTC
Permalink
Post by Christopher Key
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
Triode
2006-05-08 19:23:57 UTC
Permalink
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
Craig
2006-05-08 19:37:38 UTC
Permalink
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
Triode
2006-05-08 19:57:24 UTC
Permalink
Post by Craig
2006-05-08 20:29:20.4101 Request Task > 0.5 : 8.02541708946228
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
Post by Craig
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
Andy Grundman
2006-05-08 20:02:53 UTC
Permalink
Post by Triode
Post by Craig
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.
hickinbottoms
2006-05-08 21:29:26 UTC
Permalink
Post by 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.
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 in 6.5 since I stopped trying the web
interface while playing (which was some time ago, I'll admit).

Anyway, I hope that adds some information - it's certainly not all bad
and I'm pleasantly surprised now I've taken the time to try it again
with a more recent version. Thanks again to the developers - I'm very
pleased with my SlimServer and Squeezebox.

Let me know if any other investigation would be useful.
--
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
Andy Grundman
2006-05-08 21:44:25 UTC
Permalink
Post by hickinbottoms
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.
Triode
2006-05-08 21:46:15 UTC
Permalink
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
hickinbottoms
2006-05-09 12:45:20 UTC
Permalink
Post by 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...
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
Triode
2006-05-09 18:10:09 UTC
Permalink
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
Triode
2006-05-13 14:30:04 UTC
Permalink
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
hickinbottoms
2006-05-15 07:24:03 UTC
Permalink
Post by 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?
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
hickinbottoms
2006-05-15 23:27:16 UTC
Permalink
Post by 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?
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
Triode
2006-05-16 17:47:28 UTC
Permalink
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.
(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
Craig
2006-05-16 23:31:21 UTC
Permalink
Post by Triode
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
hickinbottoms
2006-05-17 09:53:05 UTC
Permalink
Post by 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.
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
Pat Farrell
2006-05-17 19:14:28 UTC
Permalink
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
Triode
2006-05-17 19:30:55 UTC
Permalink
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
Pat Farrell
2006-05-17 19:52:02 UTC
Permalink
Post by Triode
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.
Post by Triode
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
Pat Farrell
2006-05-17 22:09:07 UTC
Permalink
Post by Triode
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
Triode
2006-05-17 22:33:31 UTC
Permalink
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
Pat Farrell
2006-05-17 22:42:37 UTC
Permalink
Post by Triode
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
Christopher Key
2006-05-17 23:29:40 UTC
Permalink
Post by Pat Farrell
Post by Triode
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
Pat Farrell
2006-05-18 00:57:29 UTC
Permalink
Post by Christopher Key
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/slimserver/slimsoftware.html
Christopher Key
2006-05-18 09:15:06 UTC
Permalink
Post by Pat Farrell
Post by Christopher Key
Could you try ./slimserver.pl --d_startup
I've reformatted the content below to make it a little more readable
Post by Pat Farrell
(beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17>
./slimserver.pl --d_startup
/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
.
/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
Post by Pat Farrell
/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
/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
Post by Pat Farrell
/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.
[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
/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>
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).

Chris Key
Pat Farrell
2006-05-21 02:09:20 UTC
Permalink
Post by Christopher Key
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
dapnyc
2006-07-09 01:35:44 UTC
Permalink
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
snarlydwarf
2006-07-09 01:50:28 UTC
Permalink
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
dapnyc
2006-07-10 19:11:04 UTC
Permalink
Post by 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?
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
snarlydwarf
2006-07-10 19:48:04 UTC
Permalink
Post by dapnyc
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.
Post by dapnyc
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
Michael Herger
2006-07-09 17:59:24 UTC
Permalink
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/)
Triode
2006-07-09 18:55:20 UTC
Permalink
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
Christopher Key
2006-05-08 20:32:59 UTC
Permalink
Post by kdf
Post by Christopher Key
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
Dan Sully
2006-05-08 20:43:25 UTC
Permalink
* Christopher Key shaped the electrons to say...
Post by Christopher Key
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.
Not quite.

1) We're requiring perl 5.8 or higher (preferably 5.8.3) for 6.5

2) split-scanner does not use threading - it simply spawns a separate process
using Proc::Background (which does the right thing on Windows & *nix)

3) Those were thoughts for version 7. Nothing is set in stone. At this point
in time, FastCGI is likley a better alternative than mod_perl, and that's
still a big "if we decide to use Apache".
Post by Christopher Key
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.
For purposes of our conversation, "thread" should really be "multiple
processes", as Perl's threading and DBI (the database abstraction layer)
don't mix so well. Separate processes are nice, and they gain COW semantics,
as well as isolation that threads don't afford.
Post by Christopher Key
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.
One of the big blocking points with Apache is that it doesn't support UDP,
which is what the old SliMP3 protocol uses. If we are to maintain backwards
compataiblity for that product, we need a solution for UDP.

Again, Apache is only one solution. For the time being, assume we are
sticking with Perl - we have a large codebase of it already, and good
knowledge. Other solutions in the same ballpark of re-architecture include:

*) POE

*) Event::LibEvent

Which both provide async methods of handling data in and out. Both require a
pretty large rework of how the current code base is written.

Now is the time to be discussing this. Writing code is even better. :)

-D
--
<jwb> "I am POWERBOOK thy god. Thou shalt have no other laptop before me"
<gage> and the mountains shall drop sweet wine, and the hills shall melt
Andy Grundman
2006-05-08 20:49:05 UTC
Permalink
Post by Dan Sully
* Christopher Key shaped the electrons to say...
Post by Christopher Key
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.
Not quite.
1) We're requiring perl 5.8 or higher (preferably 5.8.3) for 6.5
2) split-scanner does not use threading - it simply spawns a
separate process
using Proc::Background (which does the right thing on Windows & *nix)
3) Those were thoughts for version 7. Nothing is set in stone. At this point
in time, FastCGI is likley a better alternative than mod_perl, and that's
still a big "if we decide to use Apache".
There are also pure-Perl solutions that are a lot lighter and easier
to manage, i.e. Net::Server or POE, as Dan mentioned. Or we could
use a light-weight web server such as lighttpd. Apache might be a
bit heavyweight for our needs, which, probably 9 times out of 10, is
just 1 user hitting the web server.
Dan Sully
2006-05-08 20:51:48 UTC
Permalink
* Andy Grundman shaped the electrons to say...
Post by Andy Grundman
There are also pure-Perl solutions that are a lot lighter and easier
to manage, i.e. Net::Server or POE, as Dan mentioned. Or we could
use a light-weight web server such as lighttpd. Apache might be a
bit heavyweight for our needs, which, probably 9 times out of 10, is
just 1 user hitting the web server.
Correct.

I didn't mention lighttpd, currently it needs Cygwin to run on Windows.

-D
--
<weezyl> Oh, I cook bacon naked all the time. You just have to keep the heat on med-low.
Andy Grundman
2006-05-08 20:52:22 UTC
Permalink
Post by Dan Sully
* Andy Grundman shaped the electrons to say...
Post by Andy Grundman
There are also pure-Perl solutions that are a lot lighter and
easier to manage, i.e. Net::Server or POE, as Dan mentioned. Or
we could use a light-weight web server such as lighttpd. Apache
might be a bit heavyweight for our needs, which, probably 9 times
out of 10, is just 1 user hitting the web server.
Correct.
I didn't mention lighttpd, currently it needs Cygwin to run on
Windows.
Blech, I didn't know that. I think that just requires 1 DLL though
right?
Christopher Key
2006-05-09 13:23:17 UTC
Permalink
Post by Dan Sully
For purposes of our conversation, "thread" should really be "multiple
processes", as Perl's threading and DBI (the database abstraction
layer) don't mix so well. Separate processes are nice, and they gain
COW semantics, as well as isolation that threads don't afford.
From what I've read, threads look very much more straightforward to
implement, as resources etc. can fairly readily be shared between them, and
there is no need to implement any form of IPC. Would there be a significant
amount of work involved in making the DBI thread safe? Would it instead be
possible to write wrappers around non threadsafe modules that simply passed
requests on to a single thread using that module. Slow operations using
that module would block other requests to that module, but not everything
else the system was doing. If that were a problem, the module could always
be used asynchronously.

The technique of having separate threads/processes serving each user seems
intuitively quite nice, and would remove the need to implement 'manual'
multitasking by repeatedly calling idleStreams. Even when the system is
idle, I notice somewhat jerky scrolling. I strikes me that requiring no
section of code to take longer than 140mS to execute seems a bit onerous,
and arguably adds unnecessary complexity.
Post by Dan Sully
Post by Christopher Key
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.
One of the big blocking points with Apache is that it doesn't support
UDP, which is what the old SliMP3 protocol uses. If we are to
maintain backwards compataiblity for that product, we need a solution
for UDP.
Just a though, assuming the protocols are fairly similar, could a simple
perl script be written that acted as a proxy between the two?
Post by Dan Sully
Again, Apache is only one solution. For the time being, assume we are
sticking with Perl - we have a large codebase of it already, and good
*) POE
*) Event::LibEvent
Which both provide async methods of handling data in and out. Both
require a pretty large rework of how the current code base is
written.
Now is the time to be discussing this. Writing code is even better. :)
Dan Sully
2006-05-05 17:24:15 UTC
Permalink
* kdfshaped the electrons to say...
this has been covered before. feel free to search, to avoid going
through the same exact discussion again :)
This is a good discussion to repeat however. It's been a while, and there are
new brains looking at this. I'm all for new ideas.

-D
--
<iNoah> you know, most free operating systems come preinstalled with their own high horse.
kdf
2006-05-05 17:29:52 UTC
Permalink
Post by Dan Sully
* kdfshaped the electrons to say...
this has been covered before. feel free to search, to avoid going
through the same exact discussion again :)
This is a good discussion to repeat however. It's been a while, and there are
new brains looking at this. I'm all for new ideas.
'
hence the search. new ideas good. old ideas just tiring. let's add,
not just rehash the same points. That's the advantage we have as
humans. we can record, and build upon previous efforts
Triode
2006-05-05 17:30:58 UTC
Permalink
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
Craig
2006-05-05 15:11:58 UTC
Permalink
Post by Andy Grundman
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
jonmyatt
2006-05-05 15:22:19 UTC
Permalink
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
Pat Farrell
2006-05-05 17:33:50 UTC
Permalink
Post by Craig
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
--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html
coldslabs
2006-05-05 20:07:18 UTC
Permalink
Post by Pat Farrell
Post by Craig
I'm seeing more and more problems with pausing on SB1's using flac
and
Post by Craig
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
Triode
2006-05-05 21:08:22 UTC
Permalink
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
nmizel
2006-05-05 21:22:33 UTC
Permalink
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


[***@sirius ~]# 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/0 00:00:00 grep slimserver

[***@sirius ~]# netstat -alnp | grep slimserver
tcp 0 0 0.0.0.0:9090 0.0.0.0:*
LISTEN 10976/slimserver
tcp 0 0 0.0.0.0:9000 0.0.0.0:*
LISTEN 10976/slimserver
tcp 0 0 0.0.0.0:9001 0.0.0.0:*
LISTEN 11009/slimserver
tcp 0 0 0.0.0.0:3483 0.0.0.0:*
LISTEN 10976/slimserver
tcp 0 568 192.168.1.2:3483 192.168.1.3:36684
ESTABLISHED 10976/slimserver
tcp 0 0 127.0.0.1:9090 127.0.0.1:34515
ESTABLISHED 10976/slimserver
tcp 0 21900 192.168.1.2:9000 192.168.1.3:36700
ESTABLISHED 10976/slimserver
udp 0 0 0.0.0.0:3483 0.0.0.0:*
10976/slimserver
unix 3 [ ] STREAM CONNECTED 2761469
11009/slimserver
unix 3 [ ] STREAM CONNECTED 2761457
10976/slimserver

[***@sirius 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
...

[***@sirius mizel_ch.d]# cat slimserver_proxy.conf
<IfModule !mod_proxy_html.c>
LoadFile /usr/lib/libxml2.so
LoadModule proxy_html_module modules/mod_proxy_html.so
</IfModule>

# slimserver.pl listening on port 9000
<Location /slimserver/>
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/
</Location>

# slimserver1.pl listening on port 9001
<Location /slimserver1/>
RequestHeader set Referer http://localhost:9001/
ProxyPass http://localhost:9001/
ProxyPassReverse http://localhost:9001/
SetOutputFilter proxy-html
ProxyHTMLURLMap / /slimserver/
</Location>

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

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

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

<Location /slimserver1/Default/>
SetOutputFilter proxy-html;DEFLATE
ProxyHTMLURLMap / /slimserver/
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
dont-vary
</Location>
--
nmizel
------------------------------------------------------------------------
nmizel's Profile: http://forums.slimdevices.com/member.php?userid=997
View this thread: http://forums.slimdevices.com/showthread.php?t=23641
Pat Farrell
2006-05-05 21:26:31 UTC
Permalink
Post by Triode
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
Post by Triode
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
Pat Farrell
2006-05-06 21:41:03 UTC
Permalink
Post by Pat Farrell
Post by Triode
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
Pat Farrell
2006-05-06 23:12:03 UTC
Permalink
Post by Pat Farrell
Post by Triode
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
Triode
2006-05-07 09:15:43 UTC
Permalink
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
Craig
2006-05-08 09:23:01 UTC
Permalink
Post by Triode
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
Craig
2006-05-08 10:34:02 UTC
Permalink
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
ron thigpen
2006-05-08 14:06:15 UTC
Permalink
Post by Craig
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
Robin Bowes
2006-05-08 14:33:49 UTC
Permalink
Post by ron thigpen
Post by Craig
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.
Craig
2006-05-08 15:40:57 UTC
Permalink
Post by Andy Grundman
Post by ron thigpen
Post by Craig
I'm still getting pauses when Random Mix makes a new selection but
I've
Post by ron thigpen
Post by Craig
tracked this to DBI:Find and I guess this will be covered by the
move to
Post by ron thigpen
Post by Craig
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
Dan Sully
2006-05-08 16:15:08 UTC
Permalink
* ron thigpen shaped the electrons to say...
Post by ron thigpen
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've already optimized RandomMix in the split-scanner branch.

It's the genre excluding code that's causing it.

-D
--
It is dark. You are likely to be eaten by a grue.
ron thigpen
2006-05-08 16:42:16 UTC
Permalink
Post by Dan Sully
I've already optimized RandomMix in the split-scanner branch.
It's the genre excluding code that's causing it.
Thanks Dan. Good to know it's been looked at.

I had suspected the Genre filtering and given it a go with both All
genres checked and No genres checked (on the theory that the code would
go about things differently in these cases) but it didn't seem to make
enough of a difference to matter for Sync play.

I've put up a bug for the specific case of RandomMix interacting with
Sync play, along with some ideas on fixes. One theory: a change in
timing might do the trick.

http://bugs.slimdevices.com/show_bug.cgi?id=3401

Congrats on the impending nuptials.

--rt
Dan Sully
2006-05-08 16:47:33 UTC
Permalink
* ron thigpen shaped the electrons to say...
Post by ron thigpen
I had suspected the Genre filtering and given it a go with both All
genres checked and No genres checked (on the theory that the code would
go about things differently in these cases) but it didn't seem to make
enough of a difference to matter for Sync play.
Run with --d_sql to see what's happening.

-D
--
<dr.pox> NO, NETBSD IS NOT REALLY BUILT WITH ELITE FORTRAN77!!@$#$
Dan Sully
2006-05-06 00:20:32 UTC
Permalink
* Triode shaped the electrons to say...
Post by Triode
# setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE;
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
--
<iNoah> you know, most free operating systems come preinstalled with their own high horse.
Dan Sully
2006-05-06 00:22:21 UTC
Permalink
* Dan Sully shaped the electrons to say...
Post by Dan Sully
FYI - here's a better patch which checks the size of the sndbuf first.
Oops. Let's try that again.

-D
--
<iNoah> you know, most free operating systems come preinstalled with their own high horse.
jonmyatt
2006-05-08 12:25:05 UTC
Permalink
Post by Dan Sully
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
andyg
2006-05-08 12:30:48 UTC
Permalink
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
jonmyatt
2006-05-08 12:40:55 UTC
Permalink
Post by 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
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
andyg
2006-05-08 12:47:06 UTC
Permalink
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
Pat Farrell
2006-05-08 12:47:17 UTC
Permalink
Post by andyg
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
Craig
2006-05-08 15:49:57 UTC
Permalink
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
Pat Farrell
2006-05-09 02:02:27 UTC
Permalink
Post by Craig
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
jonmyatt
2006-05-09 08:38:00 UTC
Permalink
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
Loading...