View Full Version : Rescan

Kevin Hawkins
2004-04-17, 06:35
Are people running the Windows (service) version seeing a much speedier
startup when the database cache is enabled ??

I don't see this - what happens for me is that when I startup without a
database cache the Slim Displays all power up and I can see the 'tracks'
incrementing as the server indexes my files via the information menu. I can
even use the Slim players to play music and also access the web interface. I
takes around 2 1/2 hours to index the files :-( (there are around 100K).

Once the server has done this if it is restarted and now uses the cache file
it has created (50MB) it starts up but then immediately blanks the Slim
Displays for the first 70 minutes - the web server is not useable either
(effectively I lose control of the app). This is really poor I feel . I can
see that it is accessing the music files, which are on a NAS server though
so obviously it is checking something. The memory footprint of slimsvxc
stays constant at 200MB 15% cpu usage. Even worse after this hour plus
wait with nothing apparently happening the Slim displays leap into life and
the web server runs but the indexing of the database starts AGAIN (65% cpu
and growing memory usage) - and so I then get the 2 1/2 hour wait whilst the
library builds - so the cache has served absolutely no purpose and has in
fact made things 50% worse timewise. Nothing has changed in the music
database to mean that it needed rebuilding. The cache period seems 50%
faster which looks inline with the posted figures others see in this thread
but then the index runs still :-(

What I feel the cache should do is somehow save whatever RAM / file model
the server was running with last time and restart with this 'almost
instantly' - I don't understand why it should take more than a few seconds.
If subsequently the 'cache' is found to be wrong in some way - perhaps a
file moved/deleted then it should re-run its index - keeping the exiting DB
but hopefully amending it as it goes and leaving the server useable ( rather
like a maintenance scan ) - of course the cache should still be able to be
cleared or manually kicked into a maintenance scan.

To me this is the biggest disappointemnt in the server implementation.
Aggrevated by the update recongnition being broken (via navigating into
existing music library strutures). I think this may be a Windows problem
only though is it ???

Having a user experience of an hour 'total' blank displays and a 3 1/2 hour
library build with the cache enabled (for 100K) tracks does not seem right.


> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf
> Of Tom Newton
> Sent: 17 April 2004 11:00
> To: discuss (AT) lists (DOT) slimdevices.com
> Subject: [slim] Rescan
> Pat Farrell wrote:
> > At 09:36 PM 4/16/2004, Tom Newton wrote:
> >>Any hope of ever getting either a progress indicator of
> some sort
> >>(even if you have to reload to get it do dsiplay
> "scanned foo/bar
> >>files") for the rescan?
> >
> > Oh no!
> > printing a progress indicator takes resources. :-) I'd
> rather the scan
> > go faster
> that's why I suggested one that had to be queried... :)
> > There are periodic discussions about this on the developer list.
> > I think we need more developers.
> I'm a developer... or at least I used to be :) Might code
> up a c++ rescanner as an interim measure, if I can be
> bothered to look up the database file format - might even
> make it work on winders, too :)
> > Seriously, the solution is not a progress indicator or
> even a 50%
> > improvement in scan performance. It needs to be lots smarter and
> > remember more about what it learned last time it scanned.
> > Folk are always asking for more cool stuff, and adding
> them will slow
> > down the process until it is fundamentally redesigned.
> Yeh, I can see from here that 'server needs an overhaul. :)
> --
> Tom Newton