thanks for the report.  I'm trying to get a library of the same magnitude to test with here.  with 16k 
songs, the server got occupied for only a few seconds, maybe 10.  Heavy CPU load is expected while 
searching, but not afterwards.  And the memory shouldn't increase substantially.  Is that the VM size or 
memory in use?  The VM size is the one we are interested.

CPU does drop back to normal (5%) when search is complete . It is  a big 
library I admit - how do I get the momory figures you want - I am just looking 
at the Mem usage and CPU figures in Windows Task Manager window.

Thanks.  To see the VM usage in Windows Task Manager, click on the Processes tab and then choose 
Select Columns from the View menu.  Check on Virtual Memory Size. 

 The regular Memory Size may shrink down when the OS need more memory, but the VM size shows 
how much total virtual memory the process is using.

Currently my size had grown to 352MB whilst out tonight - the VM is 397MB  - 
so I have just restarted Windows to get back the 260MB usage (I have library 
cache on btw) .
Sizes at startup are Mem 259,940K 259,000VM - the search for songs is not 
increasing VM much at all - maybe a touch - after 5 mins at 259060 and after 
10 at 259076 same after 15mins and at around 20mins I get my screens lit up 
again and 250084 usage VM    (Mem shows 260024 and Peak mem has been 264688 
all along really sincee start - is this any help ??

Left the server doing nothing overnight  have played a couple of tracks - VM 
is now up another 130MB at 397,996K mem is 343424K - no browser running

Which version of SlimServer are you running?  If it's a nightly release (5.1.6) when did you download it?

14th June was the download date - I can try downloading another if you would 
like.  Memory now seems stable at 397MB but I am not sure why it jumped from 
260 to 397MB, or even if this happened in one step  - hasn�t moved since last 
email .. K

Ah, please do upgrade to the latest nightly release:  

http://www.slimdevices.com/downloads/nightly/latest

And let me know if the memory leak and blackoug still persists.

Blackout is still there - it is 16 minutes long :-( - I estimate the search 
time as 100 tracks/sec whereas you are seeing 1600/sec on 16K tracks/10secs. 
Memory seems OK at 262MB steady - I will leave overnight and see if it jumps 
to 390MB again

I am seeing constant prolonged 99% CPU though now - is this the server 
validating the cache ?

OK 2 hours later still 99% cpu - I assume this is something to do with the 
cache being checked - but my memory has now risen to 434MB - thats 200MB more 
than it was when it launched and was useable and now on a 512MB machine I have 
no doubt got problems... 

Kevin, something very strange is going on here.  

Double check that you don't have any shortcuts in your music library that may reference another place 
in the library (causing loops or doubling of areas of the library.)  Also, check to see if you have any 
playlists in your music library that might be incorrect or refering to missing music.  

If this doesn't turn anything up, try changing your music folder to point to a folder only containing a 
few songs or albums.  See if the memory or cpu hogging problems remain.  This will help narrow the 
problem.  

If this doesn't point to a specific problem, I'd like you to do a clean uninstall of the software, then 
delete the SlimServer directory if it's still lingering.  This should reset your preferences and any cache.  

OK - it's not to do with the paths being recursive or the playlists so I guess 
its a clean install - is there anything more I can do at this stage eg with 
say the registry to make it even 'cleaner' ?  I assume there is not supposed 
then to be a memory increase after the cache rapidly loads and the later 
background verification runs - the memory should stay the same ?? 

The initial load is quick about 1 minute to show the 100K tracks but the 
background scan takes about 6 hours and 90% cpu - not worried if this is 
correct but I would have hoped any memory used here would be transient and not 
permananent as it seems to be currently - it pushes me into a constant paging 
situation in use. My initial bug re blackout for 15 mins on search for song is 
still there of course.

Vidur's database work should alleviate this issue.  

Kevin, what's your experience with the latest revisions of 6.0? Are you
satisfied enough with performance (scan and search) to close this bug?

Kevin:  is this fixed enough with 6.0?

Performance with V6 is much improved and I am not experiencing blackouts as a
direct result of the searches anymore - however I do get occasional blackouts
immediately after pressing play (on a network stored mp3).

Although 'Search' does not cause this anymore selecting 'Browse' still does .. 
The display freezes for about 30 secs and then blanks for about 20 secs with
'lost contact with server' messages on some players.  Once used once Browse
seems to work OK the next time...   Having browsed to a track and selected Play
the screen shows 'NowPlaying' but nothing does and then there's a refresh of the
screen about 30 secs later and it springs into life.  I haven't re-opened the
bug yet as if it's only the first time that this happens I can live with it.

Kevin, is this true for any of the top-level browse items? Are there specific
browse paths that are better or worse? It would also be helpful to know the
number of items (tracks/genres/artists/albums) at each level of the hierarchy
that you see this on. Thanks!

This is still an issue with 6.1  (15June build) - searching for a title
containing  a typical term like 'love' blanks displays and interrupts all
players for 4 mins - a more coommon term like 'the' results in a 16 minute
interruption.  SQL results are returned very fast it seems (few secs) but in
memory results handling seems to be a major issue.  DB is 100K tracks - Dan has
a copy.

Moving over to Dan's bug list, since he's working on performance as we speak.

Kevin - I don't think we're going to be able to get any fixes for this into 6.1 - we're under a lot of pressure 
right now. I will be addressing it as soon as possible though.

Thanks for your patience.

That's a real shame but I understand.  The bug was actually filed over a year
ago way back in 5.1 days and has been there ever since with constantly moving
target dates for a fix - v6 being the real hope.

I have 8 Slim players currently - and was considering replacing the SliMP3's
with new SB's but this issue is a real worry for me. I'll hang on in there as I
have such a dependence on SlimServer as I have Crestron , AMX, TelCanto and xAP
control via SlimServer (yep loads of HA systems here - and sort of evolving into
a demo facility setup for local HA companies) . These systems really suffer
though when the CLI stalls as of course it does - and the fact one action takes
all players down is a nightmare.

Here's waiting .. and hoping..  (for just a little longer) 

Kevin

just as an FYI, i sometimes see an on my system that is similar to one of your
symptoms.
  
call it 'idle stall'

system:
2 SB2s, almost always sync'd
wireless connection to dlink 624, 802.11g, 70-95% signal
athlon 2400, 1GB RAM, 400GB SATA HDD
WinXP sp2
35,000 track library  98%MP3, 2%FLAC

stall usually occurs on first use after some idle time
display is normal and responsive up to certain points
most noticable browsing to "new music"
as soon as right arrow is hit, display remains stuck
sometimes for minutes at a time
once it responds the first time, it is OK afterwards
similar issues on browse by artist, not as severe
'waking' the system via web interface also brings it out of the stall
occurs even when only ~50% of physical RAM is assigned

theory:
even though sufficient physical resources are available, the application is
getting into something of an idle state.  
may be OS issue
may be tunable via OS settings
(mozilla used to do a similar thing on Win)
may be memory swapping of some sort
may be db connections timing out 

workaround:
i've set up an AT (like chron) job at 30min frequency 
calls wget to fetch this URL:
http://[username]:[password]@slimserver.mydomain.org:9000/browsedb.html?hierarchy=age,track&level=0&player=00%3A04%3A20%3A05%3Aac%3A69
this remediates the problem for now.

can file separate bug on this issue if you like.

Kevin - I'm doing some performance work today.

Are you using the WebUI or the PlayerUI for your searching?

I'm using the player UI or the CLI - I very rarely use the web interface in my
setup.

Kevin

Ok - and on average, how many results are returned (when they are finally returned) ?

Could I also get a recent copy of your database? I saw you mention you just downloaded a nightly.

Thanks.

Also - what CLI commands? Could you send those along with examples?

Hi Dan,

   You already have my most recent database . Or do you want a copy of the DB as
built by the very latest 6.2 nightly that reduced my songcount by 30K ?  That's
something I haven't investigated yet but I can send it if you want.

     Re the CLI commands - I'll have to do a bit of investigating there as they
are within Freds AMX module - but I will get them. Again it is when searching
for matches to more general words in song titles (and artists to a lesser extent). 

    The number of titles returned varies up to about 2000 if you use a really
generic seach for something like 'the' but typically maybe a few hundred on
words like 'love' in a title. I will have to research this a bit as I dont
normally use the web interface  - will get back to you.  Kevin

Kevin - I just checked in some optimizations for you in subversion change 3875.

They'll be in the 08-06-2005 nightly.

Are you keeping up with Subversion?

*** Bug 1894 has been marked as a duplicate of this bug. ***

I don't know if this issue has been resolve for you folks or not, but this 
behaviour seems very much like something I've seen with particularly agressive 
virus scanners such as Kaspersky and a couple of others.  I might be way off 
base with this diagnosis in this case, but the information below might be useful 
for others in the future if I've misdiagnosed in this case.

The reports here don't seem to indicate which tasks are actually hogging the CPU 
times, causing large numbers of page faults, doing large quantities of I/O, etc. 
 This would be key information.  Large VMs don't mean very much, as that's not 
the same as increasing consumption of memory, which does matter (ie. leak).

Some virus scanners when set on more agressive modes perform a checksum on each 
file, and store that checksum and other information in an additional "stream" of 
the file.  The goal is that the virus scanner can compare the checksum 
information in its database with that in the new stream of the file more quickly 
than re-performing the checksum itself (esp. for large files).  For database 
files that change constantly (ie. slims music database), and tagged music files, 
this agressive virus scanning performs horribly, and the system spends all its 
time doing disk I/O and checksum calculations, leaving nothing for other apps.  
The result, users experience long hangs or stalls, and the system is unusable.

Reducing the agressiveness of these scanners helps resolve the problem with no 
loss of security.

For those of you who don't know how to see this information, you can add many 
more very useful pieces of data to your Windows task manager.  Under the 
Processes tab, open View->Select Columns and add all the possible columns.  For 
your Performance tab, be sure to enable View->Show kernel times as well.  During 
 the times when the system seems wedged, watch and sort by the columns that show 
most activity.

Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.