Incremental scanning -- was Re: Re: [Slimp3-checkins] CVS: slimp3/server/lib/SliMP3 HTTP.pm,1.56,1.57 Misc.pm,1.41,1.42

Discussion:

dean blackketter

2003-02-22 13:01:08 UTC

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"></style><title>Re: Incremental scanning -- was Re: [slimp3-dev]
Re: [</title></head><body>
<div>I think you are right John (see we can agree).</div>
<div><br></div>
<div>Probably turn it on at full tilt for unix variants and slower for
Windows until we can speed up windows behavior.</div>
<div><br></div>
<div>-dean</div>
<div><br></div>
<blockquote type="cite" cite>Just for reference, with Dean's help, I
turned off the incremental scan of my<br>
collection so it would get scanned as quickly as possible when the
server<br>
starts up.  My 4k albums scanned in about 10 minutes instead of >
1 day.  It<br>
never used more than 24% of my (admittedly fast) cpu.<br>
<br>
This is the behavior *I* want.  I don't ever want to run into
something that<br>
hasn't been scanned.  I don't want to contend with the scanning. 
I want to</blockquote>
<blockquote type="cite" cite>get it over once and for all as quickly
as possible.<br>
<br>
What would be wrong with making this an option? (advanced?) 
Maybe it's always<br>
what you want on linux and OSX.  (Because directory scanning is
not a problem</blockquote>
<blockquote type="cite" cite>as on windows with FAT*).<br>
<br>
Am I addressing the right issue?<br>
<br>
------------------------ Yahoo! Groups Sponsor
---------------------~--><br>
Sponsored by VeriSign - The Value of Trust<br>
Pinpoint the right security solution for your company - FREE<br>
Guide from industry leader VeriSign gives you all the facts.<br>
http://us.click.yahoo.com/lWSNbC/WdiDAA/yigFAA/rIp0lB/TM<br>
---------------------------------------------------------------------<span </span>~-><br>
<br>
To unsubscribe from this group, send an email to:<br>
slimp3-dev-unsubscribe-***@public.gmane.org<br>
<br>
 <br>
<br>
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ </blockquote>
<div><br></div>
</body>
</html>

John Ruttenberg

2002-02-07 21:57:56 UTC

Permalink

Just for reference, with Dean's help, I turned off the incremental scan of my
collection so it would get scanned as quickly as possible when the server
starts up. My 4k albums scanned in about 10 minutes instead of > 1 day. It
never used more than 24% of my (admittedly fast) cpu.

This is the behavior *I* want. I don't ever want to run into something that
hasn't been scanned. I don't want to contend with the scanning. I want to
get it over once and for all as quickly as possible.

What would be wrong with making this an option? (advanced?) Maybe it's always
what you want on linux and OSX. (Because directory scanning is not a problem
as on windows with FAT*).

Am I addressing the right issue?

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Pinpoint the right security solution for your company - FREE
Guide from industry leader VeriSign gives you all the facts.
http://us.click.yahoo.com/lWSNbC/WdiDAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

dean blackketter

2003-02-22 13:01:12 UTC

Permalink

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"></style><title>Re: [slimp3-dev] Re: [Slimp3-checkins] CVS:
slimp3/ser</title></head><body>
<div>I was thinking about the user interface impact of the addToList
problem over lunch and I finally think I can articulate what's been
bothering me about it:</div>
<div><br></div>
<div>An important quality of the user interface is that hitting a
button that actually does something have some immediate feedback as to
what it's doing.  I don't think that it's acceptable to hit the
RIGHT button and then a few seconds later have it move right.  
If you need to put up a "Please wait..." display, that's
fine, but we need to let the user know:</div>
<div>  - What's going on.</div>
<div>  - A rough idea of the progress of the thing.</div>
<div>  - A way to cancel out. </div>
<div><br></div>
<div>If you just wait until the addToList is done, they are going to
be confused when the display changes later.  If they hit
additional buttons while the addToList is going on, we need to be
careful about not having multiple things going on at once. 
Queuing up multiple commands won't cut it.  </div>
<div><br></div>
<div>Here's a scenario that will be all too common:  The user
navigates to the top of a _large_ hierarchy.  They press PLAY and
it starts scanning in the background.  While they are waiting
they press PLAY again thinking that it didn't work the first time. 
What's the right behavior?  Do we do two PLAYs in a row?  Do
we cancel the first one?  Do we ignore input while the background
loading is happening?  </div>
<div><br></div>
<div>Here are some ideas:</div>
<div><br></div>
<div>1.  If the user presses PLAY or REC and it's going to go off
and take a while to load them, we should put up a progress display
that shows how many songs have been queued up updated a couple of
times a second.  They should also be able to hit a key to stop
this process.</div>
<div><br></div>
<div>2.  If the user navigates RIGHT into an area that will take
some time to load up, a similar display that shows how many items have
been loaded and is updated a couple of times a second.  Pressing
LEFT should cancel this activity.   </div>
<div><br></div>
<div>Of course, the progress indicators shouldn't come up unless it's
been paused for more than a second or two.  Fast things should
appear fast, slow things should give the user an idea of how long they
will take.</div> <div><br></div> <div><br></div> <div><br></div> <div><br></div> <div><br></div> <blockquote type="cite" cite>> Yes.  The addToList needs to
run in the background when opening<br>
> directories and playlists.  This was causing the audio to
break up<br>
> for several windows users for large directories and probably
for<br>
> remote playlists too.<br>
<br>
I see only a few choices here:<br>
<br>
- throttle the scanning speed if the stream isn't keeping up<br>
- pause the player if you're building abig list and your surpass, say,
100<br>
  new items (ugh).<br>
- hurry up and implement the separate process for disk access<br>
<br>
#1 is the best way to go, yes? The onyly tricky part is figuring out
how<br>
much we need to reduce the scanning speed, if at all. We could just
make<br>
this a maual setting until we know how to detect it automatically.<br>
<br>
<br>
<br>
------------------------ Yahoo! Groups Sponsor
---------------------~--><br>
Sponsored by VeriSign - The Value of Trust<br>
When building an e-commerce site, you want to start with a<br>
secure foundation. Learn how with VeriSign's FREE Guide.<br>
http://us.click.yahoo.com/oCuuSA/XdiDAA/yigFAA/rIp0lB/TM<br>
---------------------------------------------------------------------<span </span>~-><br>
<br>
To unsubscribe from this group, send an email to:<br>
slimp3-dev-unsubscribe-***@public.gmane.org</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ </blockquote>
<div><br></div>
</body>
</html>

dean blackketter

2003-02-22 13:01:18 UTC

Permalink