PDA

View Full Version : slimserver.pl first startup



Kevin Walsh
2004-12-09, 10:18
Maik Musall [lists (AT) musall (DOT) de] wrote:
> On Thu, Dec 09, 2004 at 04:14:29PM -0000, Kevin Walsh wrote:
> >
> > I have the slimserver user's home directory in /opt/slimserver and
> > the SlimServer (CVS) source in /src/slimserver. I then have a symlink
> > from /opt/slimserver/server to /src/slimserver/server and another
> > from /opt/slimserver/music to somewhere else. The .slimserver.pref
> > file goes in the /opt/slimserver directory, as does the "playlists"
> > subdirectory. It all works without any drama at all.
> >
> Well I have the music directory in /mmedia/audio, but all the other
> stuff is now in /opt/slimserver which is the home directory of my
> slimp user, and it works fine now.
>
> However the server is *very* slow when rescanning, reaction to
> remote control commands or responsiveness at the web interface is
> bad. The server machine has some idle CPUs, I wonder why this isn't
> done in separate threads... or did I miss some configuration detail?
>
I don't tend to notice the rescan times as I don't rescan very often.
My SlimServer is on 24x7 and I don't buy CDs very often these days.
When I do restart the SlimServer daemon, the initial cache load takes
only a few seconds. I do delete the cache file and rescan every now
and again, but that is very rare for me. I buy new CDs a couple of
times per month, on average.

The best I can suggest (for now) is to not rescan while you're using
the server. I'm not convinced that threads would help; Threads on
Perl are evil at the moment, and most of the Perl modules on CPAN are
not thread-safe anyway. Also, unless you have multiple processors,
threading probably won't offer a lot of benefit over the current
implementation, other than to remove some load from the scheduler.

In theory, the SlimServer could fork/exec a re-scanner and could
re-load the cache file once the run has completed. If the re-scanner
script was run with a "nice" level of 10 or so then it shouldn't get
in the way too much. This is all well and good for GNU/Linux etc.,
but I have no idea whether it'll work on MS Windows.

It doesn't matter to me whether things work on MS Windows or not, but
I understand that there are a couple of die-hard MS Windows users out
there who refuse to upgrade and need to be supported. :-)

--
_/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/
_/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h
_/ _/ _/ _/ _/ _/ _/ _/_/ kevin (AT) cursor (DOT) biz
_/ _/ _/_/_/_/ _/ _/_/_/ _/ _/

kdf
2004-12-09, 18:39
Quoting Kevin Walsh <kevin (AT) cursor (DOT) biz>:

> Maik Musall [lists (AT) musall (DOT) de] wrote:
> > On Thu, Dec 09, 2004 at 04:14:29PM -0000, Kevin Walsh wrote:
> > >
> > > I have the slimserver user's home directory in /opt/slimserver and
> > > the SlimServer (CVS) source in /src/slimserver. I then have a symlink
> > > from /opt/slimserver/server to /src/slimserver/server and another
> > > from /opt/slimserver/music to somewhere else. The .slimserver.pref
> > > file goes in the /opt/slimserver directory, as does the "playlists"
> > > subdirectory. It all works without any drama at all.
> > >
> > Well I have the music directory in /mmedia/audio, but all the other
> > stuff is now in /opt/slimserver which is the home directory of my
> > slimp user, and it works fine now.
> >
> > However the server is *very* slow when rescanning, reaction to
> > remote control commands or responsiveness at the web interface is
> > bad. The server machine has some idle CPUs, I wonder why this isn't
> > done in separate threads... or did I miss some configuration detail?

its not done in separate threads because Perl is not multithreaded (please no
anti-perl stuff again). The desire is there to create separate processes in
the future, one way or another.

The music scanning always has room for speed improvement. if you are using
musicmagic integration, I've noticed that was particularly slow and have
greatly improved the responsiveness of this scan ( at the cost of the scan
taking a bit long, of course). it is part of some major rewriting I'm working
on for the various library import modules. its not ready for public
consumption yet but hopefully should be in the pre-6.0 builds soon after 5.4.1
is out.

cheers,
kdf