PDA

View Full Version : Rescan



Tom Newton
2004-04-16, 18:36
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?

Even better, how about some sort of incremental rescan? A full rescan takes
20 mins on my box :(

--

Tom Newton

Pat Farrell
2004-04-16, 18:43
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


>Even better, how about some sort of incremental rescan? A full rescan takes
>20 mins on my box :(

More like half an hour on mine.

The whole scan process is in need of a redesign. rescanning every
time the server starts is unneeded, it should be smarter. And
the scanning process needs to be lower priority so it doesn't impact
the playing of music, etc.

There are periodic discussions about this on the developer list.
I think we need more developers.

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.

Pat


Pat Farrell pfarrell (AT) pfarrell (DOT) com
http://www.pfarrell.com

Daniel Cohen
2004-04-16, 23:27
On 16/4/04 at 9:43 pm -0400, Pat Farrell wrote
>More like half an hour on mine.
>
>The whole scan process is in need of a redesign. rescanning every
>time the server starts is unneeded, it should be smarter. And
>the scanning process needs to be lower priority so it doesn't impact
>the playing of music, etc.

As I mentioned before, I have occasionally tried to rescan the music
folder from the web browser. I don't think there was much in the
music folder (not sure, as I keep various non-music subfolders inside
it). After nearly an hour, the web page was still showing "rescanning
music folder". It's possible that I did in fact have a large number
of files in the folder without realising. But should this change to
"music folder scanned" or similar words, once the scan is complete?
--
Daniel Cohen

kdf
2004-04-16, 23:52
for reference...some tests I've been doing lately:

Scan Timing, Library 340 Songs. Windows.

iTunes 4 Windows: 1.56s, 4.6ms/song
Moodlogic: 5.95s, 17.5ms/song
Raw scan: 11.86s, 34.8ms/song
Scan with DB Cache: 4.98s, 14.66ms/song

computers would all be so much better if they remembered stuff after being
turned off. Until a gigabit of flash memory is dirt cheap, it wont happen.
loading from iTunes XML is the fastest so far. Raw scanning under Linux is
faster than windows, but not faster than iTunes (tho I dont have timing numbers
for linux yet). It is also no entirely scalable.

Throwing more people at a problem isn't the answer, nor is arbitrarily doing a
total overhaul. To do so would totally sideline every other effort going. New
features are added, becuase people want them. If anything, the performance of
iTunes loading, shows what could be possible when we no longer need to open
every song in the library to find info. I had expected that loading the db
cache would be faster, and the testing continues.

-kdf

Quoting Pat Farrell <pfarrell (AT) pfarrell (DOT) com>:

> 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
>
>
> >Even better, how about some sort of incremental rescan? A full rescan takes
> >20 mins on my box :(
>
> More like half an hour on mine.
>
> The whole scan process is in need of a redesign. rescanning every
> time the server starts is unneeded, it should be smarter. And
> the scanning process needs to be lower priority so it doesn't impact
> the playing of music, etc.
>
> There are periodic discussions about this on the developer list.
> I think we need more developers.
>
> 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.
>
> Pat
>
>
> Pat Farrell pfarrell (AT) pfarrell (DOT) com
> http://www.pfarrell.com
>

Pat Farrell
2004-04-17, 00:29
At 02:52 AM 4/17/2004, kdf wrote:
>Quoting Pat Farrell <pfarrell (AT) pfarrell (DOT) com>:
> > The whole scan process is in need of a redesign. rescanning every
> > time the server starts is unneeded, it should be smarter. And
> > the scanning process needs to be lower priority so it doesn't impact
> > the playing of music, etc.


>for reference...some tests I've been doing lately:
>Scan Timing, Library 340 Songs. Windows.
>iTunes 4 Windows: 1.56s, 4.6ms/song
>Moodlogic: 5.95s, 17.5ms/song
>Raw scan: 11.86s, 34.8ms/song
>Scan with DB Cache: 4.98s, 14.66ms/song


>Throwing more people at a problem isn't the answer, nor is arbitrarily doing a
>total overhaul. To do so would totally sideline every other effort
>going. New
>features are added, becuase people want them. If anything, the performance of
>iTunes loading, shows what could be possible when we no longer need to open
>every song in the library to find info.

Brook's law says that adding people to a project makes it later,
unless the project can be broken into sequential, non-interacting
parts.

Short term, I agree with kdf.
Long term, the concept of taking even a couple milliseconds
per song on startup is unnecessary. Make it faster, is cool.
not doing unnecessary work is much better, scales better, etc.

More of a long term solution is to not have the HTML engine know
anything about bit rate codings, file formats, etc. unless the user
explicitly asks for it.

But this is a topic that belongs over on development.
It just keeps coming up because scan and startup times
are a problem now, and people are asking for more way cool
features. Incremental solutions aren't going to address
this conflict.


Pat

P McDowell
2004-04-17, 01:45
"Daniel Cohen" <danco (AT) f2s (DOT) com> wrote in message
news:a05210602bca67e256b21@[192.168.1.11]...
> On 16/4/04 at 9:43 pm -0400, Pat Farrell wrote
> >More like half an hour on mine.
> >
> >The whole scan process is in need of a redesign. rescanning every
> >time the server starts is unneeded, it should be smarter. And
> >the scanning process needs to be lower priority so it doesn't impact
> >the playing of music, etc.
>
> As I mentioned before, I have occasionally tried to rescan the music
> folder from the web browser. I don't think there was much in the
> music folder (not sure, as I keep various non-music subfolders inside
> it). After nearly an hour, the web page was still showing "rescanning
> music folder". It's possible that I did in fact have a large number
> of files in the folder without realising. But should this change to
> "music folder scanned" or similar words, once the scan is complete?
> --
> Daniel Cohen

The web browser shows "rescanning music folder" until you refresh the page.
If you refresh when the hard drive activity ceases it will show the number
of files etc

Tom Newton
2004-04-17, 02:59
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

Daniel Cohen
2004-04-17, 03:29
On 17/4/04 at 8:45 pm +1200, P McDowell wrote
>The web browser shows "rescanning music folder" until you refresh the page.
>If you refresh when the hard drive activity ceases it will show the number
>of files etc

Thanks. Some of the other things I have done (making changes, etc)
show changes immediately. I had somehow expected that "rescanning
music folder" would changer into "music folder scanned" when complete
without user action. It's fine as it is now that I know.
--
Daniel Cohen

Richard Purdie
2004-04-17, 06:40
Pat Farrell:
> The whole scan process is in need of a redesign. rescanning every
> time the server starts is unneeded, it should be smarter. And
> the scanning process needs to be lower priority so it doesn't impact
> the playing of music, etc.

Assuming you use the Tag Database feature, rescans and startup are
accelerated. If would be *very* easy to make the current slimserver load
instantly and not check anything to do with the music library but that would
confuse more users than it would please. Damned if you do, damned it you
don't really...

> There are periodic discussions about this on the developer list.
> I think we need more developers.

More developers would help but there is no easy answer which will please
everyone. Either you load instantly and don't check the data or you check
the data and the load takes longer. I have some ideas about a middle ground
solution but that needs someone to spend some time coding and I personally
haven't had time to develop them.

> 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.

It actually already does that...

It theory it should be faster than it currently seems and I'm not sure why
that is. All I can conclude is IO calls are slow under perl.

RP

Healy
2004-04-17, 06:59
On Sat, 2004-04-17 at 03:29, Daniel Cohen wrote:
> Thanks. Some of the other things I have done (making changes, etc)
> show changes immediately. I had somehow expected that "rescanning
> music folder" would changer into "music folder scanned" when complete
> without user action. It's fine as it is now that I know.

One of the things I do when I do a rescan is go back to the main page.
For the skin I use (Purple) it shows the total music count in the upper
left. While it's scanning that is blank, when it's done, it show the
stats, IE: Your music library contains 20921 songs by 1945 artists

-Healy

Pat Farrell
2004-04-17, 09:00
At 05:59 AM 4/17/2004, Tom Newton wrote:
>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 :)

Oh no, not that!!!
Seriously, while no one argues that Perl is as fast as C++,
I'd approach the problem by not doing as much, or doing it in
separate pieces so some things that are important, like playing music
get priority and are ready to happen fast, while other things like
scanning, happens rarely and is low priority when it runs while
music is playing.

If you are smart enough to write C++, you are more than
smart enough to learn Perl. The SlimServer is pretty clearly
written and structured, altho there are few overview, design docs,
architectural guidelines, etc.

Pat

Pat Farrell
2004-04-17, 09:12
At 09:40 AM 4/17/2004, Richard Purdie wrote:
>Pat Farrell:
> > The whole scan process is in need of a redesign. rescanning every
> > time the server starts is unneeded, it should be smarter. And
> > the scanning process needs to be lower priority so it doesn't impact
> > the playing of music, etc.
>
>Assuming you use the Tag Database feature, rescans and startup are
>accelerated. If would be *very* easy to make the current slimserver load
>instantly and not check anything to do with the music library but that would
>confuse more users than it would please. Damned if you do, damned it you
>don't really...

Doing the Tag Database cached will help, altho we need a more
serious commitment to upward compatibility.

There are really separate issues.
1) the scan process is so resource intensive that it ruins music playing
for a number of users. Since the point of the SlimServer is to serve music,
this is a major failure.

2) The scan process is done at startup (by default) which means that if you
want to play music NOW, you have to wait. This is bad.

And a related (less important) problem is
3) that then you are having problems with setup,
and trying things, and restarting the server over and over, you constantly
have to wait so you notice how long it takes.



> > There are periodic discussions about this on the developer list.
> > I think we need more developers.
>More developers would help

I agree, if we can segment the tasks.


>but there is no easy answer which will please
>everyone. Either you load instantly and don't check the data or you check
>the data and the load takes longer. I have some ideas about a middle ground
>solution but that needs someone to spend some time coding and I personally
>haven't had time to develop them.

There are lots of middle grounds. Looking at this as an "either/or" problem
is doomed. You have to get smarter about scanning, and have it not
destroy the joy of using the server. Very doable if that is a development
priority.



> > It needs to be lots smarter
> > and remember more about what it learned last time it scanned.
>It actually already does that...

Rather, recent releases attempt to do that.
Even with the database cache, there are problems
whenever you need a rescan, such as when you add a new
CD to your library. And we all buy CDs to make artists happy
and to keep the RIAA happy.

I've spend twice as much on new CDs since I got my SqueezeBox than
I spent on the SqueezeBox itself. And I started wth 500 or so CDs.

>It theory it should be faster than it currently seems and I'm not sure why
>that is. All I can conclude is IO calls are slow under perl.

It is more than just IO being slow. It is doing way too much.
It is parsing the music file formats to extract all sorts of internal
information, including bit rates, format, names of lyrics, cover art, etc.
All of which are useful in themselves, and represent useful features.

And the feature requests keep coming in, as they should.

It is clear to me that the correct long term solution is a major restructuring
of the code. It is not at all clear when the long term is here.

Pat

kdf
2004-04-17, 09:28
Quoting Pat Farrell <pfarrell (AT) pfarrell (DOT) com>:


> There are really separate issues.
> 1) the scan process is so resource intensive that it ruins music playing
> for a number of users. Since the point of the SlimServer is to serve music,
> this is a major failure.

The scan is, in fact, slowed down to a scheduled pace in order to allow other
things to happen

> 2) The scan process is done at startup (by default) which means that if you
> want to play music NOW, you have to wait. This is bad.

requirements of the device mean music must be scanned before it plays. You may
not need all of the songs, but you do need the ones that are about to play. The
eventual goal would be to be able to play (without dropouts) while scanning
continues. however, there will always be lesser CPU's that will take too long.
One way to get instant playback....winamp.

>
> And a related (less important) problem is
> 3) that then you are having problems with setup,
> and trying things, and restarting the server over and over, you constantly
> have to wait so you notice how long it takes.

and a great technique is to have a dual install, with a smaller library while
testing. You can swap songs in and out, which helps narrow down when the
problems are song related.

-kdf

Richard Purdie
2004-04-17, 09:44
> There are really separate issues.
> 1) the scan process is so resource intensive that it ruins music playing
> for a number of users. Since the point of the SlimServer is to serve
music,
> this is a major failure.

If it's less intensive, it takes longer. There is middle ground though and I
think there are settings in the server which can be altered to change the
rate at which is does the scanning.

> 2) The scan process is done at startup (by default) which means that if
you
> want to play music NOW, you have to wait. This is bad.

I agree and I can think of an easy way to solve that particular problem as
it happens. I'm reluctant to add settings to the server as Slim Devices
would rather it was simple to use. I don't think the current defaults suit
everybody though and I will look into that.

> And a related (less important) problem is
> 3) that then you are having problems with setup,
> and trying things, and restarting the server over and over, you constantly
> have to wait so you notice how long it takes.

If 1 and 2 are solved, 3 goes away...

> > > It needs to be lots smarter
> > > and remember more about what it learned last time it scanned.
> >It actually already does that...
>
> Rather, recent releases attempt to do that.

We're trying our best. If you can see an obvious way these "attempts" can be
improved, please feel free to discuss them on the developers list.

> It is more than just IO being slow. It is doing way too much.
> It is parsing the music file formats to extract all sorts of internal
> information, including bit rates, format, names of lyrics, cover art, etc.
> All of which are useful in themselves, and represent useful features.

I think you misunderstand the way the server works internally if you think
this information "too much". If you're going to extract one ID3 tag, you may
as well do the lot. We all agree improvement is needed but I would like
people to understand why the current code does what it does before
condemning it.

> It is clear to me that the correct long term solution is a major
restructuring
> of the code. It is not at all clear when the long term is here.

I've been trying to establish the long term aims for this section of code on
the developers list.

I think the way forward is for me to submit some changes to the system in
the short term which solve or at least improve some of the problems. I think
I can do that without causing too much disruption and without a major
rewrite.

Cheers,

RP

Tom Newton
2004-04-18, 08:43
Pat Farrell wrote:

> At 05:59 AM 4/17/2004, Tom Newton wrote:
>>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 :)
>
> Oh no, not that!!!
> Seriously, while no one argues that Perl is as fast as C++,
> I'd approach the problem by not doing as much, or doing it in
> separate pieces so some things that are important, like playing music
> get priority and are ready to happen fast, while other things like
> scanning, happens rarely and is low priority when it runs while
> music is playing.

It is a bit of a problem that you can't "double buffer" - ie. continue to
use old, stale information whilst new stuff was being created, either in
RAM or on disk for later mem-mapping.

> If you are smart enough to write C++, you are more than
> smart enough to learn Perl. The SlimServer is pretty clearly

I know Perl pretty well, that's why I don't like it ;)

> written and structured, altho there are few overview, design docs,
> architectural guidelines, etc.

Will have a poke when I get time... any docs at all? A good starting point?

--

Tom Newton

Richard Purdie
2004-04-18, 09:04
Tom Newton:
> It is a bit of a problem that you can't "double buffer" - ie. continue to
> use old, stale information whilst new stuff was being created, either in
> RAM or on disk for later mem-mapping.

Using the cache whilst it's being updated may be the ultimate result of
development I have in mind. The patch I've just submitted is a step in that
direction.

> > If you are smart enough to write C++, you are more than
> > smart enough to learn Perl. The SlimServer is pretty clearly
>
> I know Perl pretty well, that's why I don't like it ;)

It's not my favourite either. Like everything, it has advantages and
disadvantages though and for the Slim Server it's not a bad choice...

> > written and structured, altho there are few overview, design docs,
> > architectural guidelines, etc.
>
> Will have a poke when I get time... any docs at all? A good starting
point?

I'm not sure a C++ rescanner is going to be especially useful to be honest
as it's a fork in development to an incompatible language rather than an
effort on the existing system. Obviously you're free to do what you want
though ;-). The only docs on the Caching system/Tag Database are in the FAQ
or in emails sent to the developers list.

RP

Donald B. Lagosz-Sinclair
2004-04-19, 06:55
Without knowing the way the scan database is organized, or exactly how SlimServer uses it, and making the assumption that music is generally only added to a library (and rarely removed), here are my thoughts as a software designer:

1. Since the rescan time only worsens with each CD added, rescans should only be done when requested.

2. To minimize the pain when you've just brought a new CD home, there should be two scan databases: the one created from the last full rescan, and a "new additions" database, which shows up as a separate item in the "Browse" menu. This has the nice side benefit of segregating the newer material into a shorter, easier-to-browse list. It's probably only necessary to have the "new additions" listed by album, i.e. "Browse new albums".

3. After ripping a new CD, an option in the browser allows incorporating it into the "new additions" database.

4. At some convenient time (like overnight), a full rescan is run, which empties out the "new additions" database. Ideally, it should be possible tell SlimServer to rescan at a particular time, either once, or on a regular schedule.

I have no idea how much work this entails, but it seems to avoid the problems with the player being unusable for a lengthy period when restarting the server, and having to wait to hear new music.

-:- dbls


----- Original Message -----
From: "Richard Purdie" <rpurdie (AT) rpsys (DOT) net>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Sunday, April 18, 2004 12:04 PM
Subject: [slim] Rescan


> Tom Newton:
> > It is a bit of a problem that you can't "double buffer" - ie. continue to
> > use old, stale information whilst new stuff was being created, either in
> > RAM or on disk for later mem-mapping.
>
> Using the cache whilst it's being updated may be the ultimate result of
> development I have in mind. The patch I've just submitted is a step in that
> direction.
>
> > > If you are smart enough to write C++, you are more than
> > > smart enough to learn Perl. The SlimServer is pretty clearly
> >
> > I know Perl pretty well, that's why I don't like it ;)
>
> It's not my favourite either. Like everything, it has advantages and
> disadvantages though and for the Slim Server it's not a bad choice...
>
> > > written and structured, altho there are few overview, design docs,
> > > architectural guidelines, etc.
> >
> > Will have a poke when I get time... any docs at all? A good starting
> point?
>
> I'm not sure a C++ rescanner is going to be especially useful to be honest
> as it's a fork in development to an incompatible language rather than an
> effort on the existing system. Obviously you're free to do what you want
> though ;-). The only docs on the Caching system/Tag Database are in the FAQ
> or in emails sent to the developers list.
>
> RP
>
>

David N. Blank-Edelman
2004-04-19, 07:27
On Sun, Apr 18, 2004 at 05:04:08PM +0100, Richard Purdie wrote:
> I'm not sure a C++ rescanner is going to be especially useful to be honest
> as it's a fork in development to an incompatible language rather than an
> effort on the existing system.

Actually, this gives me a half-baked idea (that maybe should hit the
devel list instead). Would there be any benefit to spinning off an
optimized rescanning program upon request that just signaled the main
server when it was done?

A few pluses if this were done:

o Said program (written in any language) could also, if this made any
sense, be run periodically in a cron-like fashion. It could be as smart
as it wants to be about how much I/O it actually needs to do each time
it is called.

o Breaking this code off from the main server would also allow people to
write competing implementations.

o The stream/UI server would not have to live on the same box as the
indexer (though in most cases, it probably would). Potentially benefits
people with huge collections.

Note: I realize this goes in the opposite direction of trying to do
scanning incrementally in a "lazy" fashion, but isn't necessarily
incompatible with that notion.


-- dNb

Daryle A. Tilroe
2004-04-19, 07:57
I have been playing around with 5.1.3 for a bit and like
the fact that the scroll speed is now adjustable. However
it appears that it only affects the scroll speed of the
small display/font. When the big display/font is used
it seems to go at the same rate. Are others seeing this?
What would probably be the most useful is to have the larger
font have a separate scroll speed and delay or else do it as
a proportion of the small font speed and delay.


--
Daryle A. Tilroe

Daryle A. Tilroe
2004-04-19, 17:52
Daryle A. Tilroe wrote:

>
> I have been playing around with 5.1.3 for a bit and like
> the fact that the scroll speed is now adjustable. However
> it appears that it only affects the scroll speed of the
> small display/font. When the big display/font is used
> it seems to go at the same rate. Are others seeing this?
> What would probably be the most useful is to have the larger
> font have a separate scroll speed and delay or else do it as
> a proportion of the small font speed and delay.
>
>

OK I have tested this some more and the speed on the large display
is definitely not affected by the scroll speed setting. So before
I open a report; does anyone know if this is a minor bug or a
major feature enhancement?

--
Daryle A. Tilroe

dean
2004-04-19, 20:40
Minor bug. Please file it on http://bugs.slimdevices.com

On Apr 19, 2004, at 5:52 PM, Daryle A. Tilroe wrote:

> Daryle A. Tilroe wrote:
>
>> I have been playing around with 5.1.3 for a bit and like
>> the fact that the scroll speed is now adjustable. However
>> it appears that it only affects the scroll speed of the
>> small display/font. When the big display/font is used
>> it seems to go at the same rate. Are others seeing this?
>> What would probably be the most useful is to have the larger
>> font have a separate scroll speed and delay or else do it as
>> a proportion of the small font speed and delay.
>
> OK I have tested this some more and the speed on the large display
> is definitely not affected by the scroll speed setting. So before
> I open a report; does anyone know if this is a minor bug or a
> major feature enhancement?
>
> --
> Daryle A. Tilroe
>
>

kdf
2004-04-19, 21:18
actually, it works fine for me.
the speed isn't affected as drasticly, but it should change. try a value of
0.01 and see. Tis flying by barely readable for me in large size. Total blur in
small. I'll double check my version against cvs, but I'm pretty sure its been
identical for some time.

-kdf

Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> Minor bug. Please file it on http://bugs.slimdevices.com
>
> On Apr 19, 2004, at 5:52 PM, Daryle A. Tilroe wrote:
>
> > Daryle A. Tilroe wrote:
> >
> >> I have been playing around with 5.1.3 for a bit and like
> >> the fact that the scroll speed is now adjustable. However
> >> it appears that it only affects the scroll speed of the
> >> small display/font. When the big display/font is used
> >> it seems to go at the same rate. Are others seeing this?
> >> What would probably be the most useful is to have the larger
> >> font have a separate scroll speed and delay or else do it as
> >> a proportion of the small font speed and delay.
> >
> > OK I have tested this some more and the speed on the large display
> > is definitely not affected by the scroll speed setting. So before
> > I open a report; does anyone know if this is a minor bug or a
> > major feature enhancement?
> >
> > --
> > Daryle A. Tilroe
> >
> >

Daryle A. Tilroe
2004-04-19, 22:00
kdf wrote:

> actually, it works fine for me.
> the speed isn't affected as drasticly, but it should change. try a value of
> 0.01 and see. Tis flying by barely readable for me in large size. Total blur in
> small. I'll double check my version against cvs, but I'm pretty sure its been
> identical for some time.

I get the blur with 0.01 on small but large still plods along. I am
running 5.1.3 with v20; what are you on?

--
Daryle A. Tilroe

kdf
2004-04-19, 22:16
Quoting "Daryle A. Tilroe" <daryle (AT) micralyne (DOT) com>:

> kdf wrote:
>
> > actually, it works fine for me.
> > the speed isn't affected as drasticly, but it should change. try a value
> of
> > 0.01 and see. Tis flying by barely readable for me in large size. Total
> blur in
> > small. I'll double check my version against cvs, but I'm pretty sure its
> been
> > identical for some time.
>
> I get the blur with 0.01 on small but large still plods along. I am
> running 5.1.3 with v20; what are you on?

a couple beers and some amazing playoff hockey!! ;)
....but other than that, latest cvs and firmware v21. However this has been
working for me for some time, ever since I patched the scrollrate feature.

-kdf

michael
2004-04-22, 12:34
Pat Farrell <pfarrell (AT) pfarrell (DOT) com> writes:
....
> Even with the database cache, there are problems
> whenever you need a rescan, such as when you add a new
> CD to your library. And we all buy CDs to make artists happy
> and to keep the RIAA happy.

One handy workaround until this gets fixed...
When you add a new CD to your collection, don't hit the rescan
button. Instead navigate to your new CD through "Browse my music folder".
When you find the new files, they'll automatically be added to your
music library, and you can now find them under
browse/search artists/albums/songs etc.

This obviously isn't a solution to the core problem, but until that's
fixed, if you're just adding a CD or two, this is faster than a
complete rescan (particularly for a large collection).

hope that helps someone.

-michael
--
"The power of accurate observation is frequently called cynicism
by those who don't have it."
- George Bernard Shaw