Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 5 of 5
  1. #1
    Laurent Perez
    Guest

    100% cpu problems == fixed (yay!)

    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

  2. #2
    Neil Cameron
    Guest

    100% cpu problems == fixed (yay!)

    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

  3. #3
    Neil Cameron
    Guest

    100% cpu problems == fixed (yay!)

    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

  4. #4
    Laurent Perez
    Guest

    100% cpu problems == fixed (yay!)

    > 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

  5. #5
    NOT a Slim Devices Employee kdf's Avatar
    Join Date
    Apr 2005
    Posts
    9,493

    100% cpu problems == fixed (yay!)

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •