PDA

View Full Version : 100% cpu problems == fixed (yay!)



Laurent Perez
2004-07-20, 11:48
Hi

After yet another attempt of finding why recent slimserver versions
were eating all my cpu ressources while indexing my library, I finally
found the problem :) I did enable several logging options from
slimserver, patiently waited for cpu rise, refreshing
http://localhost:9000/log.txt.

The problem lied in a looping windows shortcut present in one of my
directories, i.e d:\foomusic\shortuct_to_d:\foomusic.lnk. I deleted it
and of course cpu usage lowered back to normal. I know it was already
mentionned on the list, but I was certain to have wiped out any
looping shortcuts from my library, guess I was wrong ;) (this one was
probably created by an unexpected drag&drop>create shortcut mouse
gesture within explorer).

I suggest people with 100% cpu problems should look for *.lnk files
inside their music library (windows+f) and delete the looping ones.
Searching for shorcuts inside hundred of music directories can be
painful, so automatic search is better.

Now for the smart fix : I think slimserver should not follow shortcuts
pointing to a directory which name matches (think regexp) the previous
directory, something like remembering the last indexed directory would
be fine. I guess you can't expect anyone to have a 'pure' library
without looping shortcuts. Maybe a stronger fix would be to stop using
shortcuts to index music directories on several partitions, and
instead use 1 to 10 possible paths of indexing - I doubt everyone uses
more than 10 device paths to put their library in.

cheers
laurent

Neil Cameron
2004-07-23, 01:11
I think you've cracked it - and perfect timing Laurent - I have been having
this problem for some time, but it got really bad recently - just after my
kids used my iTunes to add some songs to their iPod. I thought I'd just
leave SlimServer running all night to let it get whatever it was out of its
system - but in the morning it was still running at 99% CPU capacity! Then
I saw your email, and found two folder links that they had managed to add.
and deleted them. Then slim.exe activity went down to about 2%.
Then I took the bull by the horns and initiated a rescan manually. Although
slim.exe went up to 99% it never stopped the Squeezeboxes working, as it had
before, and after 3 mins it had finished and was back to normal.

Thanks

Just as a matter of interest - what is your setting for iTunes Reload
Interval?

--
Neil

"Laurent Perez" <hakimm (AT) gmail (DOT) com> wrote in
message news:501089280407201148169d060e (AT) mail (DOT) gmail.com...
> Hi
>
> After yet another attempt of finding why recent slimserver versions
> were eating all my cpu ressources while indexing my library, I finally
> found the problem :) I did enable several logging options from
> slimserver, patiently waited for cpu rise, refreshing
> http://localhost:9000/log.txt.
>
> The problem lied in a looping windows shortcut present in one of my
> directories, i.e d:\foomusic\shortuct_to_d:\foomusic.lnk. I deleted it
> and of course cpu usage lowered back to normal. I know it was already
> mentionned on the list, but I was certain to have wiped out any
> looping shortcuts from my library, guess I was wrong ;) (this one was
> probably created by an unexpected drag&drop>create shortcut mouse
> gesture within explorer).
>
> I suggest people with 100% cpu problems should look for *.lnk files
> inside their music library (windows+f) and delete the looping ones.
> Searching for shorcuts inside hundred of music directories can be
> painful, so automatic search is better.
>
> Now for the smart fix : I think slimserver should not follow shortcuts
> pointing to a directory which name matches (think regexp) the previous
> directory, something like remembering the last indexed directory would
> be fine. I guess you can't expect anyone to have a 'pure' library
> without looping shortcuts. Maybe a stronger fix would be to stop using
> shortcuts to index music directories on several partitions, and
> instead use 1 to 10 possible paths of indexing - I doubt everyone uses
> more than 10 device paths to put their library in.
>
> cheers
> laurent

Neil Cameron
2004-07-23, 05:19
I guess I spoke too soon!
It now rescans about every hour, and for about 10 mins of that stops
responding to commands and won't let me start a web session. My iTunes
Reload Interval is set to 36000 seconds=10 hrs.
Back to the drawing board? This is getting really frustrating!
--
Neil


"Neil Cameron" <ncameron (AT) msn (DOT) com> wrote in message
news:cdqh85$10m$1 (AT) sea (DOT) gmane.org...
> I think you've cracked it - and perfect timing Laurent - I have been
having
> this problem for some time, but it got really bad recently - just after my
> kids used my iTunes to add some songs to their iPod. I thought I'd just
> leave SlimServer running all night to let it get whatever it was out of
its
> system - but in the morning it was still running at 99% CPU capacity!
Then
> I saw your email, and found two folder links that they had managed to add.
> and deleted them. Then slim.exe activity went down to about 2%.
> Then I took the bull by the horns and initiated a rescan manually.
Although
> slim.exe went up to 99% it never stopped the Squeezeboxes working, as it
had
> before, and after 3 mins it had finished and was back to normal.
>
> Thanks
>
> Just as a matter of interest - what is your setting for iTunes Reload
> Interval?
>
> --
> Neil
>
> "Laurent Perez" <hakimm (AT) gmail (DOT) com> wrote in
> message
news:501089280407201148169d060e (AT) mail (DOT) gmail.com...
> > Hi
> >
> > After yet another attempt of finding why recent slimserver versions
> > were eating all my cpu ressources while indexing my library, I finally
> > found the problem :) I did enable several logging options from
> > slimserver, patiently waited for cpu rise, refreshing
> > http://localhost:9000/log.txt.
> >
> > The problem lied in a looping windows shortcut present in one of my
> > directories, i.e d:\foomusic\shortuct_to_d:\foomusic.lnk. I deleted it
> > and of course cpu usage lowered back to normal. I know it was already
> > mentionned on the list, but I was certain to have wiped out any
> > looping shortcuts from my library, guess I was wrong ;) (this one was
> > probably created by an unexpected drag&drop>create shortcut mouse
> > gesture within explorer).
> >
> > I suggest people with 100% cpu problems should look for *.lnk files
> > inside their music library (windows+f) and delete the looping ones.
> > Searching for shorcuts inside hundred of music directories can be
> > painful, so automatic search is better.
> >
> > Now for the smart fix : I think slimserver should not follow shortcuts
> > pointing to a directory which name matches (think regexp) the previous
> > directory, something like remembering the last indexed directory would
> > be fine. I guess you can't expect anyone to have a 'pure' library
> > without looping shortcuts. Maybe a stronger fix would be to stop using
> > shortcuts to index music directories on several partitions, and
> > instead use 1 to 10 possible paths of indexing - I doubt everyone uses
> > more than 10 device paths to put their library in.
> >
> > cheers
> > laurent

Laurent Perez
2004-07-23, 09:02
> My iTunes reload Interval is set to 36000 seconds=10 hrs.
> Back to the drawing board? This is getting really frustrating!

I've also had indexing troubles after installing iTunes - I bought an
ipod few weeks after the Squeezebox - so here are my "fixes" to iTunes
scanning problem (which sadly I can't reproduce, but I'm pretty sure
"something" is wrong with iTunes indexing) :

- stop using iTunes and use Ephpod instead, it has same
functionnalities if you're using iTunes because of iPod. note that
Ephpod might fuck up your iPod alarm clock if you are using it (known
Apple bug, not even fixed on fourth gen. iPod afaik)
- do not tell slimserver to index iTunes playlists, instead do as followed :

..run itunes, run winamp
..delete winamp current playlist
..within itunes, select a playlist (or library, whatever), highlist
wanted files and drag'n'drop them onto winamp window, this will add
them to current playlist
..save your current winamp playlist as m3u file into your slimserver
playlists directory
..you will then have the "same" playlist from itunes converted to m3u
and indexable by slimserver

this is a dirty hack (mostly because itunes doesnt save playlists in
m3u format <grind>nice move from Apple</grind>) but it will get the
job done after a few mouse clicks. you may also want to use winamp5
because it has advanced playlists options (like click on a list and
have contextual menu Send to > playlist_name) which makes the process
faster especially if you have many playlists.

true that playlists management is still a no-no from slimserver, it
should need some interface rewriting (like when you can't update/erase
a playlist because the saved name has to be different ?)

laurent

kdf
2004-07-23, 10:29
Quoting Laurent Perez <hakimm (AT) gmail (DOT) com>:
> true that playlists management is still a no-no from slimserver, it
> should need some interface rewriting (like when you can't update/erase
> a playlist because the saved name has to be different ?)

This is in teh tracking system as bug 355:
http://bugs.slimdevices.com/show_bug.cgi?id=355

I've just submitted a patch if you feel up to testing it and giving your
feedback in the bug tracker. I'm not sure yet how to keep the playlist name
persistant, but this patch will allow you the option to confirm an overwrite of
an existing playlist. So far, the patch is only for the fishbone skin, which
also allows a link to edit a playlist (which DOES already save over the
existing one when you edit).

-kdf