After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 337778 - rhythmbox takes a long time to load 25,000 files.
rhythmbox takes a long time to load 25,000 files.
Status: RESOLVED DUPLICATE of bug 325215
Product: rhythmbox
Classification: Other
Component: general
0.9.3
Other All
: Normal minor
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-09 09:06 UTC by Ivan Matveich
Modified: 2006-04-09 11:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ivan Matveich 2006-04-09 09:06:04 UTC
Please describe the problem:
rhythmbox takes two minutes to load 25,000 files when it is first invoked.

rhythmbox takes twenty seconds to load 25,000 files the next time.

Other music players skip while rhythmbox is loading.

Steps to reproduce:
Start rhythmbox with a large library, especially after a reboot.

Actual results:
Rhythmbox takes 20 to 120 seconds to load its library.

Expected results:
Rhythmbox loads its library quickly (eg, in a few seconds.)

Does this happen every time?
Yes.

Other information:
Looks like rhythmbox lstat64's each file, presumably to prune non-existent files
from the library. Personally, I want to disable this scan altogether by a
command-line switch or a gconf key; are you open to such a patch?

I'll leave you to ponder a more general solution. For instance, you might do the
scan gently in the background after every n days.
Comment 1 James "Doc" Livingston 2006-04-09 09:25:08 UTC
This has been greatly improved in cvs since 0.9.3 was released, and bug 325215 details the efforts to improve this (both completed and furthur work).

Some of the changes to improve this:
* for local files, existance is remembered between sessions, so tracks can be made visible before the stats are done.
* stats are not started until after Rhythmbox has completely loaded the UI and database, and are done with a lower gnome-vfs priority.
* the stats are passed to gnome-vfs as one batch rather than individually, stopping helping to stop it getting overloaded with requests.

If you have furthur ideas, please comment on that bug.

*** This bug has been marked as a duplicate of 325215 ***
Comment 2 Ivan Matveich 2006-04-09 11:41:16 UTC
OK, shame on me for not trying CVS first. Yeah, I see that it's postponing the flurry of lstat64s until after loading the tracks. Good, that helps. I'll see if I still have skipping problems with other running players because of the heavy disk activity; if so, that could be fixed by doing the lstats more slowly.

Anyway, it's still kind of slow: it takes 25 seconds for my 25,000 files to be made visible on an 1800mhz athlon-xp. But I have no clue how to optimize that...