PDA

View Full Version : 100% processor



2004-10-04, 12:28
Yes. After upgrading to 5.3 I experienced serious problems with Slimserver
locking up due to processor usage. It was the reason I downgraded to 5.2.1
again, which is more stable for me and seems to use much less memory.
Running on WinXP SP2.

Bye
Peter


-----Original Message-----
From: Beesley, S [mailto:sbeesley (AT) dsl (DOT) pipex.com]
Sent: Monday, October 04, 2004 8:58 PM
To: Slim Devices Discussion
Subject: [slim] 100% processor


Since 5.3.1 I cannot get slim running without the processor running at 100%.
It seems to be rebuilding the cache. This has not been a problem on any
other prior version for me. It seems to run for a few seconds and then
effectively jams the PC at 100%. I have tried this with debug/log files on
and also by watching the slimserver.db size. It randomly stops at different
places (Windows XP).

Has anybody else seen this?

Beesley, S
2004-10-04, 12:33
MessageI've just confirmed this. I downgraded to 2004-10-02.exe build and all is OK again. It is the scan that is causing the problem. On this version, the scan takes 3 mins and processor stays at 30% max. On the latest build, the processor is on 100% and does not finish.
(could this be some of the DRM WMA detection that has been built into the scan)?
On a related note, why does the cache has non music files in it (e.g. ..ini and .dat)?
----- Original Message -----
From: slim (AT) vcooten (DOT) nl
To: 'Slim Devices Discussion'
Sent: Monday, October 04, 2004 8:28 PM
Subject: [slim] 100% processor


Yes. After upgrading to 5.3 I experienced serious problems with Slimserver locking up due to processor usage. It was the reason I downgraded to 5.2.1 again, which is more stable for me and seems to use much less memory. Running on WinXP SP2.

Bye
Peter

-----Original Message-----
From: Beesley, S [mailto:sbeesley (AT) dsl (DOT) pipex.com]
Sent: Monday, October 04, 2004 8:58 PM
To: Slim Devices Discussion
Subject: [slim] 100% processor


Since 5.3.1 I cannot get slim running without the processor running at 100%. It seems to be rebuilding the cache. This has not been a problem on any other prior version for me. It seems to run for a few seconds and then effectively jams the PC at 100%. I have tried this with debug/log files on and also by watching the slimserver.db size. It randomly stops at different places (Windows XP).

Has anybody else seen this?




------------------------------------------------------------------------------

kdf
2004-10-04, 12:47
that is something you can easily test yourself. Move the DRM stuff from the
library and see if the performance improves.

your request for the microsoft-style multi-artist was also added. All of thise
requires a full rescan, thus installing this nightly will cause a wipe cache.

as for teh related note, those types of files are only known to appear of you
have a stray shortcut in your library.

-kdf

Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:

> MessageI've just confirmed this. I downgraded to 2004-10-02.exe build and all
> is OK again. It is the scan that is causing the problem. On this version, the
> scan takes 3 mins and processor stays at 30% max. On the latest build, the
> processor is on 100% and does not finish.
> (could this be some of the DRM WMA detection that has been built into the
> scan)?
> On a related note, why does the cache has non music files in it (e.g. .ini
> and .dat)?
> ----- Original Message -----
> From: slim (AT) vcooten (DOT) nl
> To: 'Slim Devices Discussion'
> Sent: Monday, October 04, 2004 8:28 PM
> Subject: [slim] 100% processor
>
>
> Yes. After upgrading to 5.3 I experienced serious problems with Slimserver
> locking up due to processor usage. It was the reason I downgraded to 5.2.1
> again, which is more stable for me and seems to use much less memory. Running
> on WinXP SP2.
>
> Bye
> Peter
>
> -----Original Message-----
> From: Beesley, S [mailto:sbeesley (AT) dsl (DOT) pipex.com]
> Sent: Monday, October 04, 2004 8:58 PM
> To: Slim Devices Discussion
> Subject: [slim] 100% processor
>
>
> Since 5.3.1 I cannot get slim running without the processor running at
> 100%. It seems to be rebuilding the cache. This has not been a problem on any
> other prior version for me. It seems to run for a few seconds and then
> effectively jams the PC at 100%. I have tried this with debug/log files on
> and also by watching the slimserver.db size. It randomly stops at different
> places (Windows XP).
>
> Has anybody else seen this?
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>

Beesley, S
2004-10-04, 14:33
Sorry, I should have been clearer. I have no DRM files in the place that
Slim is looking. But I was wondering if the changes to the code anyway were
causing problems.
----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Monday, October 04, 2004 8:47 PM
Subject: [slim] 100% processor


> that is something you can easily test yourself. Move the DRM stuff from
> the
> library and see if the performance improves.
>
> your request for the microsoft-style multi-artist was also added. All of
> thise
> requires a full rescan, thus installing this nightly will cause a wipe
> cache.
>
> as for teh related note, those types of files are only known to appear of
> you
> have a stray shortcut in your library.
>
> -kdf
>
> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>
>> MessageI've just confirmed this. I downgraded to 2004-10-02.exe build and
>> all
>> is OK again. It is the scan that is causing the problem. On this version,
>> the
>> scan takes 3 mins and processor stays at 30% max. On the latest build,
>> the
>> processor is on 100% and does not finish.
>> (could this be some of the DRM WMA detection that has been built into the
>> scan)?
>> On a related note, why does the cache has non music files in it (e.g.
>> .ini
>> and .dat)?
>> ----- Original Message -----
>> From: slim (AT) vcooten (DOT) nl
>> To: 'Slim Devices Discussion'
>> Sent: Monday, October 04, 2004 8:28 PM
>> Subject: [slim] 100% processor
>>
>>
>> Yes. After upgrading to 5.3 I experienced serious problems with
>> Slimserver
>> locking up due to processor usage. It was the reason I downgraded to
>> 5.2.1
>> again, which is more stable for me and seems to use much less memory.
>> Running
>> on WinXP SP2.
>>
>> Bye
>> Peter
>>
>> -----Original Message-----
>> From: Beesley, S [mailto:sbeesley (AT) dsl (DOT) pipex.com]
>> Sent: Monday, October 04, 2004 8:58 PM
>> To: Slim Devices Discussion
>> Subject: [slim] 100% processor
>>
>>
>> Since 5.3.1 I cannot get slim running without the processor running
>> at
>> 100%. It seems to be rebuilding the cache. This has not been a problem on
>> any
>> other prior version for me. It seems to run for a few seconds and then
>> effectively jams the PC at 100%. I have tried this with debug/log files
>> on
>> and also by watching the slimserver.db size. It randomly stops at
>> different
>> places (Windows XP).
>>
>> Has anybody else seen this?
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>

kdf
2004-10-04, 14:45
ok, well one other thing to note.
there is a difference in terminology here. A rescan is done on every startup of
slimserver. This involves simply loading the data from teh slimserver.db cache
file. This is often very quick (3minutes) and simple (30% load). However,
when there are changes to teh info that is required in the cache, the DBVERSION
number is increased which forces the cache to be wiped. This is what occurs in
todays nightly build. Much of the time, this isn't needed, but some nightlies
will cause this to happen. During this scan, the server will intensely search
and index all yoru chosen sources. Thsi includes use of iTunes and Moodlogic,
as well as the music folder setting, if it exists. This scan can take a very
long time depending on the type of music and where it is located. Scanning
over a network mapped drive is very slow, for example. Windows filesystems in
general also seem to be a bit slower.

If you have installed the latest nightly, on any day, and the DB has changed,
you will have to wait for it to rebuild the cache. 100% cpu is entirely like
for this time, as is the inability to play music, depending on your system
configuration. A great deal of effort has been expended in order to make this
happen as little as possible, hence the shorted rescan on most startups.
however for certain features to be implemented, the cache must be rebuilt and
you have to be patient. If your server is crashing, then THAT is something to
investigate. Fro that, run teh server from a command line adding --d_info
--logfile mylog.txt, then look for the point where the server crashes.

-kdf

Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:

> Sorry, I should have been clearer. I have no DRM files in the place that
> Slim is looking. But I was wondering if the changes to the code anyway were
> causing problems.
> ----- Original Message -----
> From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Monday, October 04, 2004 8:47 PM
> Subject: [slim] 100% processor
>
>
> > that is something you can easily test yourself. Move the DRM stuff from
> > the
> > library and see if the performance improves.
> >
> > your request for the microsoft-style multi-artist was also added. All of
> > thise
> > requires a full rescan, thus installing this nightly will cause a wipe
> > cache.
> >
> > as for teh related note, those types of files are only known to appear of
> > you
> > have a stray shortcut in your library.
> >
> > -kdf
> >
> > Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
> >
> >> MessageI've just confirmed this. I downgraded to 2004-10-02.exe build and
> >> all
> >> is OK again. It is the scan that is causing the problem. On this version,
> >> the
> >> scan takes 3 mins and processor stays at 30% max. On the latest build,
> >> the
> >> processor is on 100% and does not finish.
> >> (could this be some of the DRM WMA detection that has been built into the
> >> scan)?
> >> On a related note, why does the cache has non music files in it (e.g.
> >> .ini
> >> and .dat)?
> >> ----- Original Message -----
> >> From: slim (AT) vcooten (DOT) nl
> >> To: 'Slim Devices Discussion'
> >> Sent: Monday, October 04, 2004 8:28 PM
> >> Subject: [slim] 100% processor
> >>
> >>
> >> Yes. After upgrading to 5.3 I experienced serious problems with
> >> Slimserver
> >> locking up due to processor usage. It was the reason I downgraded to
> >> 5.2.1
> >> again, which is more stable for me and seems to use much less memory.
> >> Running
> >> on WinXP SP2.
> >>
> >> Bye
> >> Peter
> >>
> >> -----Original Message-----
> >> From: Beesley, S [mailto:sbeesley (AT) dsl (DOT) pipex.com]
> >> Sent: Monday, October 04, 2004 8:58 PM
> >> To: Slim Devices Discussion
> >> Subject: [slim] 100% processor
> >>
> >>
> >> Since 5.3.1 I cannot get slim running without the processor running
> >> at
> >> 100%. It seems to be rebuilding the cache. This has not been a problem on
> >> any
> >> other prior version for me. It seems to run for a few seconds and then
> >> effectively jams the PC at 100%. I have tried this with debug/log files
> >> on
> >> and also by watching the slimserver.db size. It randomly stops at
> >> different
> >> places (Windows XP).
> >>
> >> Has anybody else seen this?
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> >>

Beesley, S
2004-10-04, 14:51
Sorry, I am not being clear. I am wiping the cache and building it from
scratch. I have also tried deleting the .db file.
- With the .EXE from 2004-10-02 (and prior), upon startup the cache rebuild
takes 3 mins and the load is 30% max
- With the .EXE from 2004-10-03 and 2004-10-04, upon startup the processor
jumps to 100% and after 2 hours it still has not completed
There is a change / difference / problem with these latest builds.

----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Monday, October 04, 2004 10:45 PM
Subject: [slim] 100% processor


> ok, well one other thing to note.
> there is a difference in terminology here. A rescan is done on every
> startup of
> slimserver. This involves simply loading the data from teh slimserver.db
> cache
> file. This is often very quick (3minutes) and simple (30% load).
> However,
> when there are changes to teh info that is required in the cache, the
> DBVERSION
> number is increased which forces the cache to be wiped. This is what
> occurs in
> todays nightly build. Much of the time, this isn't needed, but some
> nightlies
> will cause this to happen. During this scan, the server will intensely
> search
> and index all yoru chosen sources. Thsi includes use of iTunes and
> Moodlogic,
> as well as the music folder setting, if it exists. This scan can take a
> very
> long time depending on the type of music and where it is located.
> Scanning
> over a network mapped drive is very slow, for example. Windows
> filesystems in
> general also seem to be a bit slower.
>
> If you have installed the latest nightly, on any day, and the DB has
> changed,
> you will have to wait for it to rebuild the cache. 100% cpu is entirely
> like
> for this time, as is the inability to play music, depending on your system
> configuration. A great deal of effort has been expended in order to make
> this
> happen as little as possible, hence the shorted rescan on most startups.
> however for certain features to be implemented, the cache must be rebuilt
> and
> you have to be patient. If your server is crashing, then THAT is
> something to
> investigate. Fro that, run teh server from a command line adding --d_info
> --logfile mylog.txt, then look for the point where the server crashes.
>
> -kdf
>
> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>
>> Sorry, I should have been clearer. I have no DRM files in the place that
>> Slim is looking. But I was wondering if the changes to the code anyway
>> were
>> causing problems.
>> ----- Original Message -----
>> From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
>> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
>> Sent: Monday, October 04, 2004 8:47 PM
>> Subject: [slim] 100% processor
>>
>>
>> > that is something you can easily test yourself. Move the DRM stuff
>> > from
>> > the
>> > library and see if the performance improves.
>> >
>> > your request for the microsoft-style multi-artist was also added. All
>> > of
>> > thise
>> > requires a full rescan, thus installing this nightly will cause a wipe
>> > cache.
>> >
>> > as for teh related note, those types of files are only known to appear
>> > of
>> > you
>> > have a stray shortcut in your library.
>> >
>> > -kdf
>> >
>> > Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>> >
>> >> MessageI've just confirmed this. I downgraded to 2004-10-02.exe build
>> >> and
>> >> all
>> >> is OK again. It is the scan that is causing the problem. On this
>> >> version,
>> >> the
>> >> scan takes 3 mins and processor stays at 30% max. On the latest build,
>> >> the
>> >> processor is on 100% and does not finish.
>> >> (could this be some of the DRM WMA detection that has been built into
>> >> the
>> >> scan)?
>> >> On a related note, why does the cache has non music files in it (e.g.
>> >> .ini
>> >> and .dat)?
>> >> ----- Original Message -----
>> >> From: slim (AT) vcooten (DOT) nl
>> >> To: 'Slim Devices Discussion'
>> >> Sent: Monday, October 04, 2004 8:28 PM
>> >> Subject: [slim] 100% processor
>> >>
>> >>
>> >> Yes. After upgrading to 5.3 I experienced serious problems with
>> >> Slimserver
>> >> locking up due to processor usage. It was the reason I downgraded to
>> >> 5.2.1
>> >> again, which is more stable for me and seems to use much less memory.
>> >> Running
>> >> on WinXP SP2.
>> >>
>> >> Bye
>> >> Peter
>> >>
>> >> -----Original Message-----
>> >> From: Beesley, S [mailto:sbeesley (AT) dsl (DOT) pipex.com]
>> >> Sent: Monday, October 04, 2004 8:58 PM
>> >> To: Slim Devices Discussion
>> >> Subject: [slim] 100% processor
>> >>
>> >>
>> >> Since 5.3.1 I cannot get slim running without the processor
>> >> running
>> >> at
>> >> 100%. It seems to be rebuilding the cache. This has not been a problem
>> >> on
>> >> any
>> >> other prior version for me. It seems to run for a few seconds and then
>> >> effectively jams the PC at 100%. I have tried this with debug/log
>> >> files
>> >> on
>> >> and also by watching the slimserver.db size. It randomly stops at
>> >> different
>> >> places (Windows XP).
>> >>
>> >> Has anybody else seen this?
>> >>
>> >>
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >>
>> >>
>> >>

kdf
2004-10-04, 15:03
Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:

> Sorry, I am not being clear. I am wiping the cache and building it from
> scratch. I have also tried deleting the .db file.
> - With the .EXE from 2004-10-02 (and prior), upon startup the cache rebuild
> takes 3 mins and the load is 30% max
> - With the .EXE from 2004-10-03 and 2004-10-04, upon startup the processor
> jumps to 100% and after 2 hours it still has not completed
> There is a change / difference / problem with these latest builds.
>
ok well, I'll just walk away then and let someone intelligent figure out your
issue. :)
-kdf

dean
2004-10-04, 16:46
How big is your library and how fast is your computer?

The slimserver.db file format changed in the 5.3.1 release, so a full
cache rebuild is required, which may take some time. But 2 hours is
way too long...

-dean

On Oct 4, 2004, at 3:03 PM, kdf wrote:

> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>
>> Sorry, I am not being clear. I am wiping the cache and building it
>> from
>> scratch. I have also tried deleting the .db file.
>> - With the .EXE from 2004-10-02 (and prior), upon startup the cache
>> rebuild
>> takes 3 mins and the load is 30% max
>> - With the .EXE from 2004-10-03 and 2004-10-04, upon startup the
>> processor
>> jumps to 100% and after 2 hours it still has not completed
>> There is a change / difference / problem with these latest builds.
>>
> ok well, I'll just walk away then and let someone intelligent figure
> out your
> issue. :)
> -kdf
>

Beesley, S
2004-10-05, 01:30
5000 songs, 2GHZ processor.
BTW - after 2 hours, it still doesn't complete.
I tried to do some debugging and the .db file stops growing seconds after
the rebuild starts. Also, the processor is 100%, but the hard disk light is
not flashing (as normal when doing a rebuild). With the --d_scan
and --d_info options, the log stops at different places after just a few
minutes..

----- Original Message -----
From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Tuesday, October 05, 2004 12:46 AM
Subject: [slim] 100% processor


> How big is your library and how fast is your computer?
>
> The slimserver.db file format changed in the 5.3.1 release, so a full
> cache rebuild is required, which may take some time. But 2 hours is way
> too long...
>
> -dean
>
> On Oct 4, 2004, at 3:03 PM, kdf wrote:
>
>> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>>
>>> Sorry, I am not being clear. I am wiping the cache and building it from
>>> scratch. I have also tried deleting the .db file.
>>> - With the .EXE from 2004-10-02 (and prior), upon startup the cache
>>> rebuild
>>> takes 3 mins and the load is 30% max
>>> - With the .EXE from 2004-10-03 and 2004-10-04, upon startup the
>>> processor
>>> jumps to 100% and after 2 hours it still has not completed
>>> There is a change / difference / problem with these latest builds.
>>>
>> ok well, I'll just walk away then and let someone intelligent figure out
>> your
>> issue. :)
>> -kdf
>>

John Gorst
2004-10-05, 06:23
I had a similar problem the other day upgrading from one of the nightly
rpm packages from pre 5.3.1 to one post 5.3.1

Problem solved by installing the 'official' 5.3.1. I put it down to that
particular nightly being buggered, but it could be a problem upgrading
between versions?

Beesley, S wrote:
> 5000 songs, 2GHZ processor.
> BTW - after 2 hours, it still doesn't complete.
> I tried to do some debugging and the .db file stops growing seconds
> after the rebuild starts. Also, the processor is 100%, but the hard disk
> light is not flashing (as normal when doing a rebuild). With the
> --d_scan and --d_info options, the log stops at different places after
> just a few minutes..
>
> ----- Original Message ----- From: "dean blackketter"
> <dean (AT) slimdevices (DOT) com>
> To: "Slim Devices Discussion"
> <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Tuesday, October 05, 2004 12:46 AM
> Subject: [slim] 100% processor
>
>
>> How big is your library and how fast is your computer?
>>
>> The slimserver.db file format changed in the 5.3.1 release, so a full
>> cache rebuild is required, which may take some time. But 2 hours is
>> way too long...
>>
>> -dean
>>
>> On Oct 4, 2004, at 3:03 PM, kdf wrote:
>>
>>> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>>>
>>>> Sorry, I am not being clear. I am wiping the cache and building it from
>>>> scratch. I have also tried deleting the .db file.
>>>> - With the .EXE from 2004-10-02 (and prior), upon startup the cache
>>>> rebuild
>>>> takes 3 mins and the load is 30% max
>>>> - With the .EXE from 2004-10-03 and 2004-10-04, upon startup the
>>>> processor
>>>> jumps to 100% and after 2 hours it still has not completed
>>>> There is a change / difference / problem with these latest builds.
>>>>
>>> ok well, I'll just walk away then and let someone intelligent figure
>>> out your
>>> issue. :)
>>> -kdf
>>>

kdf
2004-10-05, 10:33
Hi Stuart,

I just downloaded the Oct 5 Windows build and tried it out. I Do get spikes up
to 95 percent after a wipe cache, but it doesn't lock up. Of course, this is
only on a small windows test system with 450 songs, 6 of which are WMA. one is
DRM and one is multi-artist, both to test recent bug fixes. It wouldn't appear
that the DRM fix or the multi-artist fix are the problem, at least not
single-handedly.

Dean may have a better idea of what is happening, but if you want to try some
testing, try setting your music folder to various subfolders of your main one
to reduce the song count and maybe even the types of songs it must scan. It
will help a lot to narrow down what might be the cause.

I've got 5k songs on another machine, 700MHz which I'll try tonight just to see
if I can reproduce.

as for debugging, if d_scan and d_info are getting nowhere, try d_moodlogic or
d_itunes if you are using either of those. also d_http, or even d_artwork, or
all of them together.

feel free to past the last bits of the logs, even if they do look a bit
different. It just has to be hte last bits (say 10 lines of each), becuase you
can't send too big a message to this list.

Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:

> 5000 songs, 2GHZ processor.
> BTW - after 2 hours, it still doesn't complete.
> I tried to do some debugging and the .db file stops growing seconds after
> the rebuild starts. Also, the processor is 100%, but the hard disk light is
> not flashing (as normal when doing a rebuild). With the --d_scan
> and --d_info options, the log stops at different places after just a few
> minutes..
>
> ----- Original Message -----
> From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Tuesday, October 05, 2004 12:46 AM
> Subject: [slim] 100% processor
>
>
> > How big is your library and how fast is your computer?
> >
> > The slimserver.db file format changed in the 5.3.1 release, so a full
> > cache rebuild is required, which may take some time. But 2 hours is way
> > too long...
> >
> > -dean
> >
> > On Oct 4, 2004, at 3:03 PM, kdf wrote:
> >
> >> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
> >>
> >>> Sorry, I am not being clear. I am wiping the cache and building it from
> >>> scratch. I have also tried deleting the .db file.
> >>> - With the .EXE from 2004-10-02 (and prior), upon startup the cache
> >>> rebuild
> >>> takes 3 mins and the load is 30% max
> >>> - With the .EXE from 2004-10-03 and 2004-10-04, upon startup the
> >>> processor
> >>> jumps to 100% and after 2 hours it still has not completed
> >>> There is a change / difference / problem with these latest builds.
> >>>
> >> ok well, I'll just walk away then and let someone intelligent figure out
> >> your
> >> issue. :)
> >> -kdf
> >>

Beesley, S
2004-10-07, 15:07
see bug 608. I have found a file that causes the problem and uploaded it.
----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Tuesday, October 05, 2004 6:33 PM
Subject: [slim] 100% processor


> Hi Stuart,
>
> I just downloaded the Oct 5 Windows build and tried it out. I Do get
> spikes up
> to 95 percent after a wipe cache, but it doesn't lock up. Of course, this
> is
> only on a small windows test system with 450 songs, 6 of which are WMA.
> one is
> DRM and one is multi-artist, both to test recent bug fixes. It wouldn't
> appear
> that the DRM fix or the multi-artist fix are the problem, at least not
> single-handedly.
>
> Dean may have a better idea of what is happening, but if you want to try
> some
> testing, try setting your music folder to various subfolders of your main
> one
> to reduce the song count and maybe even the types of songs it must scan.
> It
> will help a lot to narrow down what might be the cause.
>
> I've got 5k songs on another machine, 700MHz which I'll try tonight just
> to see
> if I can reproduce.
>
> as for debugging, if d_scan and d_info are getting nowhere, try
> d_moodlogic or
> d_itunes if you are using either of those. also d_http, or even
> d_artwork, or
> all of them together.
>
> feel free to past the last bits of the logs, even if they do look a bit
> different. It just has to be hte last bits (say 10 lines of each),
> becuase you
> can't send too big a message to this list.
>
> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>
>> 5000 songs, 2GHZ processor.
>> BTW - after 2 hours, it still doesn't complete.
>> I tried to do some debugging and the .db file stops growing seconds after
>> the rebuild starts. Also, the processor is 100%, but the hard disk light
>> is
>> not flashing (as normal when doing a rebuild). With the --d_scan
>> and --d_info options, the log stops at different places after just a few
>> minutes..
>>
>> ----- Original Message -----
>> From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
>> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
>> Sent: Tuesday, October 05, 2004 12:46 AM
>> Subject: [slim] 100% processor
>>
>>
>> > How big is your library and how fast is your computer?
>> >
>> > The slimserver.db file format changed in the 5.3.1 release, so a full
>> > cache rebuild is required, which may take some time. But 2 hours is
>> > way
>> > too long...
>> >
>> > -dean
>> >
>> > On Oct 4, 2004, at 3:03 PM, kdf wrote:
>> >
>> >> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>> >>
>> >>> Sorry, I am not being clear. I am wiping the cache and building it
>> >>> from
>> >>> scratch. I have also tried deleting the .db file.
>> >>> - With the .EXE from 2004-10-02 (and prior), upon startup the cache
>> >>> rebuild
>> >>> takes 3 mins and the load is 30% max
>> >>> - With the .EXE from 2004-10-03 and 2004-10-04, upon startup the
>> >>> processor
>> >>> jumps to 100% and after 2 hours it still has not completed
>> >>> There is a change / difference / problem with these latest builds.
>> >>>
>> >> ok well, I'll just walk away then and let someone intelligent figure
>> >> out
>> >> your
>> >> issue. :)
>> >> -kdf
>> >>

Dan Sully
2004-10-07, 16:45
* Beesley, S <sbeesley (AT) dsl (DOT) pipex.com> shaped the electrons to say...

>see bug 608. I have found a file that causes the problem and uploaded it.

Fixed - next nightly (or if you sync cvs) will fix it.

-D
--
<weezyl> $6.66: The Value Meal of the Beast.

Beesley, S
2004-10-08, 11:24
Yippee! The latest build (with this fix) cures the problem, rescan is back
to 30% and 5 mins (from 2 hours + at 100%)

----- Original Message -----
From: "Dan Sully" <daniel (AT) electricrain (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Friday, October 08, 2004 12:45 AM
Subject: [slim] 100% processor


>* Beesley, S <sbeesley (AT) dsl (DOT) pipex.com> shaped the electrons to say...
>
>>see bug 608. I have found a file that causes the problem and uploaded it.
>
> Fixed - next nightly (or if you sync cvs) will fix it.
>
> -D
> --
> <weezyl> $6.66: The Value Meal of the Beast.
>

kdf
2004-10-08, 11:36
good to hear! don't forget to close off the bug report :)

-kdf


Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:

> Yippee! The latest build (with this fix) cures the problem, rescan is back
> to 30% and 5 mins (from 2 hours + at 100%)
>
> ----- Original Message -----
> From: "Dan Sully" <daniel (AT) electricrain (DOT) com>
> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Friday, October 08, 2004 12:45 AM
> Subject: [slim] 100% processor
>
>
> >* Beesley, S <sbeesley (AT) dsl (DOT) pipex.com> shaped the electrons to say...
> >
> >>see bug 608. I have found a file that causes the problem and uploaded it.
> >
> > Fixed - next nightly (or if you sync cvs) will fix it.
> >
> > -D
> > --
> > <weezyl> $6.66: The Value Meal of the Beast.
> >