erland;578431 Wrote: 
> Isn't the correct type of rescan performed already today automatically
> by the system if you change one of the options that requires it ?
> I know it at least happens if you change the "separator for multiple
> tag values" setting.
> 
> From a user perspective it shouldn't be important if the system
> performs:
> - A rescan from files
> - A rescan from stage 1 database
> As long as it's fast and gives the correct result, the users will be
> happy.

i think you're missing the point i am making...  if i change an option
in SBS, like the ones you or Jim mentioned, SBS should NOT need to
rescan the files, new or full; it should simply rebuild the SBS tables
from the tag cache table (phase 1) or better yet it should just make
ALL the tables it could ever need regardless of the toggle type
options, and then just switch to those tables when the option is
changed.

in what i am proposing, phase one just makes the raw tag cache table,
and that should be updated whenever the OS detects file changes.  at
that point, phase two should kick in and make all the tables SBS would
ever need, in the background, and the options would just control final
display of data to the user, and have nothing to do with needing a
rescan, (in most cases).

i can not understate how much i HATE IT when SBS kicks off some
"automatic rescan" or requests one.  it shouldn't ever be necessary
UNLESS data changed, but not when [most] options change.

erland;578431 Wrote: 
> I suspect most(all?) of the current options that requires a rescan works
> this way. Most users only sets them once in a new installation and never
> change them after that.
> 
> This is also the reason why the only reason to implement a two phase
> system in current SBS would be if it gets too hard to handle all the
> fringe cases in the incremental rescan without it.
> 
> The performance isn't an reason as a two stage process probably won't
> speed up incremental rescans, it will only speed up full rescans. The
> main idea is that you should rarely have to do a full rescan since the
> options that requires this often are changed only once in a specific
> setup.
> 
> With the "new schema" approach, the situation was a lot different
> because then it was a lot more probable that a user would adjust the
> schema which would require a full rescan.

ok, that all sounds true, but i want to emphasize a few things here:

1. i would rather have a two phase system where you don't need to look
for fringe cases that you may never even be aware of, but exist
nonethelss.

1a. i would rather have a fullproof system that doesn't need
"attention" to fix like mynb's example.

2. i don't want to have to rescan because options change.  TPE2 is a
perfect example.  b/c of the dumb "one master list" display SBS uses, i
have to decide between using albumartist tags for my master sbs list, or
artist tags, and stick with it, unless i masochistically want to full
clear and rescan everytime i want to flip between them.  dumb!

if both tables for the TPE2 option were made during the second phase of
a scan, i could just switch between them by toggling the option. 
(although i want to stress that this issue is equally a UI downfall,
not just a scanning one)

in other words, winamp lets me browse and sort between AA and artist
via a click, and i can even display them together.  all thats a fat NO
CAN DO on SBS, without screwing with the TPE2 option, and a full
rescan, YUK!

3. the scanner right now is, imo, opaque at best.  if you had a raw tag
table for phase one, you could figure out pretty quick where a problem
was, be it in how a tag is read, OR in the phase2 logic.

4. all this stuff could happen in the background.

i agree with Greg and i thought you...


-- 
MrSinatra

www.lion-radio.org
using:
sb2 & sbc (my home) / sbrec & ipeng (parent's home) - sbs 7.5.2b - win
xp pro sp3 ie8 - p4(ht) 3.2ghz, 2gig ram - 1tb wd usb2 raid1 - d-link
dir-655 - 43k+ mp3
------------------------------------------------------------------------
MrSinatra's Profile: http://forums.slimdevices.com/member.php?userid=2336
View this thread: http://forums.slimdevices.com/showthread.php?t=82096

_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta

Reply via email to