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 323096 - Rhythmbox causes gam_server to consume large amounts of CPU usage
Rhythmbox causes gam_server to consume large amounts of CPU usage
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: general
HEAD
Other All
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-12-03 11:18 UTC by Nicholas Allen
Modified: 2008-08-11 13:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to make monitoring optional (9.70 KB, patch)
2005-12-05 04:30 UTC, James "Doc" Livingston
committed Details | Review
patch to make it *really* optional (757 bytes, patch)
2005-12-10 12:40 UTC, James "Doc" Livingston
none Details | Review
fixed patch (1.60 KB, patch)
2005-12-11 10:23 UTC, James "Doc" Livingston
committed Details | Review

Description Nicholas Allen 2005-12-03 11:18:12 UTC
Please describe the problem:
When I run rhythmbox the gam_server process (I think it is some kind of file
monitoring daemon) consumes large amounts of CPU (60-70%) the whole time that
rhythmbox is loaded. I am pretty sure this did not happen a few days ago so
seems to be a new bug introduced in head (as of 3/12/05).

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 James "Doc" Livingston 2005-12-03 11:39:31 UTC
If you have set your library location in the preferences, Rhythmbox monitors it
for new files (which will use gam_server, I guess). It shouldn't cause
gam_server to use a lot of CPU though, unless there is a bug in that.

What distro and version of gamin are you using?
Comment 2 Nicholas Allen 2005-12-03 17:22:39 UTC
I am using Ubuntu but it seems to be a change in rhythmbox that caused this and
nothing to do with gamin. This is because I was using HEAD a few days ago and
there was no problem at all. I also just installed 0.9.2 and there is no problem
with that version either. It only occurrs with the changes made in the last few
days from CVS head. My gamin version is 0.1.5ubuntu1.
Comment 3 Alex Lancaster 2005-12-04 14:17:59 UTC
I see a similar problem, although I can't see the gam_server issues, but
rhythmbox keeps flashing "Loading...", then back to the
"songs/days/hours/minutes" view periodically ever 2-3 seconds, causing a CPU
usage spike every time it does so.  If I leave it running for a while, it will
eventually stop.  I also get a lot of console messages that are identical to:

(rhythmbox:4169): GStreamer-CRITICAL **: gst_bin_remove_func: assertion
`GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed

This is against HEAD as of the time of this bug report.

I think it is related to the preferences for this new feature of watched
directories.  I didn't set a preference, but when I go to preferences, it is set
to "Home", and it starts indexing my entire home directory, without me asking it
to.  Seems like there should be an option  not to watch any directories at all.
   (I tried removing the key value completely in the gconf editor, but it still
defaults to Home).

I am very picky about how I maintain my rhythmbox db, and which directories it
indexes and I don't like rhythmbox deciding what it should index without asking
me.  The default should be "None".
Comment 4 James "Doc" Livingston 2005-12-05 04:28:47 UTC
Ah. The code is able to deal with not having a location set - but the
preferences widget doesn't, and sets it to Home when the preferences are opened.
I'm making a patch to fix this.


With respect to the gam_server cpu usage, I'm seeing this with Breezy also (but
not in Ubuntu Dapper). Running "rhythmbox -d 2>&1 | egrep 'monitor|directory'"
shows that Rhythmbox is receiving lots of file-monitor events - it's getting a
Create, a Modify, then a Delete event for things that I moved to the trash the
other day. There are a fair few bugs filed about similar problems with gamin
0.1.5 in Breezy, so I guess it's a problem with that.
Comment 5 James "Doc" Livingston 2005-12-05 04:30:47 UTC
Created attachment 55617 [details] [review]
patch to make monitoring optional

This patch adds a checkbox to turn off monitoring.
Comment 6 Alex Lancaster 2005-12-05 12:42:52 UTC
Patch appears to work, although it still shows a default location of "Home".  
Even if its not used for monitoring, it could be confusing for users.  Is there
a way of "greying-out" the option?
Comment 7 James "Doc" Livingston 2005-12-05 13:14:07 UTC
Yes, but I delibrately didn't do that.

Although the option currently doesn't do anything when monitoring is turned off,
it will be used for other things (soon hopefully). In particular things like CD
ripping and copying files off iPods, will need to know where your library is.
Comment 8 James "Doc" Livingston 2005-12-05 13:14:28 UTC
patch committed to cvs
Comment 9 Alex Lancaster 2005-12-05 13:46:41 UTC
I still have a problem with CPU usage even with the monitoring switched off.  It
still appears to take a while to settle down after I restart rhythmbox, with the
periodic "Loading..." messages and many: 

(rhythmbox:4169): GStreamer-CRITICAL **: gst_bin_remove_func: assertion
`GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed

messages appearing on the console.
Comment 10 Alex Lancaster 2005-12-05 14:05:09 UTC
Running in ("-d") debug mode, I see repeated attempts to read the metadata from
the same file over and over again:

[0x923af60] [rb_metadata_gst_load_tag] rb-metadata-gst.c:395 (01:02:45): uri:
file:///home/alex/mp3/complete-rips/Pop%20Will%20Eat%20Itself/Amalgamation/04%20RSVP%20(Apollo%20440%2012%22).mp3
tag: bitrate
[0x923af60] [rb_metadata_gst_fakesink_handoff_cb] rb-metadata-gst.c:488
(01:02:45): in fakesink handoff
[0x923af60] [rb_metadata_load] rb-metadata-gst.c:661 (01:02:45): duration query
succeeded
[0x923af60] [rb_metadata_load] rb-metadata-gst.c:716 (01:02:45): successfully
read metadata for
file:///home/alex/mp3/complete-rips/Pop%20Will%20Eat%20Itself/Amalgamation/04%20RSVP%20(Apollo%20440%2012%22).mp3

(rhythmbox:11304): GStreamer-CRITICAL **: gst_bin_remove_func: assertion
`GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed
[0x923af60] [rb_metadata_save] rb-metadata-gst.c:813 (01:02:45): saving metadata
for uri:
file:///home/alex/mp3/complete-rips/Pop%20Will%20Eat%20Itself/Amalgamation/04%20RSVP%20(Apollo%20440%2012%22).mp3
[0x923af60] [rb_metadata_gst_add_tag_data] rb-metadata-gst.c:763 (01:02:45):
Setting title
[0x923af60] [rb_metadata_gst_add_tag_data] rb-metadata-gst.c:763 (01:02:45):
Setting replaygain-track-peak
[0x923af60] [rb_metadata_gst_add_tag_data] rb-metadata-gst.c:763 (01:02:45):
Setting artist
Comment 11 James "Doc" Livingston 2005-12-05 14:20:44 UTC
Are you trying to change the tags on any files? because the second one is a
metadata write, not a read. I've just realised something nasty: Rhythmbox
created the temporary tag-writing file in the same directory as the original -
which causes it to be notified of the new file.

Unchecking the checkbox doesn't stop file monitoring, it just doesn't add new
files. Rhythmbox will still monitor all the files in your library, so that it
knows when they are deleted/changed. 0.9.0 should have done that kind of
monitoring too, although due to a bug it sometimes didn't.
Comment 12 Alex Lancaster 2005-12-05 14:37:46 UTC
Yes, I am using tagtool to retag (not rhythmbox, because it doesn't appear to
have a way of updating the Year across multiple files which is irritating
because it can do Genre).  I can see that as soon as I change the pref (even
with the file monitoring switched off) it attempts to update the file.

[0x82b7728] [rb_playlist_manager_save_playlists] rb-playlist-manager.c:775
(01:30:45): no save needed, ignoring
[0x82b7728] [rb_library_source_preferences_sync] rb-library-source.c:1145
(01:30:47): syncing pref dialog state
[0x82b7728] [rb_library_source_preferences_sync] rb-library-source.c:1157
(01:30:47): syncing library location file:///home/alex/mp3/BenWalsh/

I would like to have a way to completely stop monitoring and only update the
info upon an explicit file or directory import.
Comment 13 Alex Lancaster 2005-12-05 14:46:27 UTC
> I've just realised something nasty: Rhythmbox created the temporary tag-writing 
> file in the same directory as the original - which causes it to be notified of 
> the new file.

Yes, I think the read-write of the tag is somehow getting caught in a race
condition, even though I'm not using rhythmbox to do the tagging.
Comment 14 James "Doc" Livingston 2005-12-06 02:25:11 UTC
I've just committed some fixes (which include the patch on bug 323094) that
should help prevent these kinds of issues.

We should really have a way for the metadata saving code to tell the DB to
ignore certain files and never load them (for the temporary files). However as
long as the metadata saving doesn't pause and not touch the file for a few
seconds half way though, it should be okay.
Comment 15 Nicholas Allen 2005-12-06 19:05:00 UTC
I just got the latest version from CVS and this problem is still there.
gam_server uses 70%CPU every half a second or so - even while rhythmbox is doing
nothing. If I exit rb then gam_server goes down to 0% CPU so it is something
that rb seems to be doing...
Comment 16 James "Doc" Livingston 2005-12-07 08:39:22 UTC
Ah, I've discovered the problem:
When a file changes, RB reloads the metadata and sets it for the entry. This
causes a SYNC operation which write the metadata to disk, which means the file
has changed, so RB reloads the metadata...


I'll try to fix this soon.
Comment 17 James "Doc" Livingston 2005-12-07 09:03:18 UTC
This should (hopefully) be fixed now.
Comment 18 Nicholas Allen 2005-12-07 22:03:15 UTC
I just updated from CVS but I am still noticing the CPU spikes by gam_server -
strange as that sounded like the situation that would cause this problem. If you
are having difficulty reproducing it I can try to help debug it as it is 100%
reproducable on my machine. 
Comment 19 James "Doc" Livingston 2005-12-08 01:41:55 UTC
Try running "rhythmbox -d 2>&1 | egrep 'monitor|directory'". It will print out a
lot of stuff at startup, but once RB is running it will tell you the "directory
events" it recieves (which are notifications from gamin).

When you're seeing the high cpu usage, can you look at what it has printed out
and post it here? (it will probably be the same several lines repeating).
Comment 20 Nicholas Allen 2005-12-09 20:04:48 UTC
I see a lot of lines printed during startup and then once rb is loaded
gam_server is still consuming large amounts of CPU at regular intervals of about
0.5 seconds but there is absolutely nothing printed out on the console during
this time. Only as rb loads do I see any messages being printed but once loade
nothing further is printed out.
Comment 21 James "Doc" Livingston 2005-12-10 03:25:44 UTC
Do you know if you have an inotify-enabled kernel? If not, then it could be
gam_server polling for changes. Since Rhythmbox is asking it to watch a large
number of directories, that might be taking up a bit of cpu.
Comment 22 Nicholas Allen 2005-12-10 11:32:25 UTC
I do not have a /dev/inotify so my understanding is that this means I do not
have an inotify enabled kernel. So this could definately be the reason why gamin
is using so much CPU. I guess something changed in rb that asks gamin to monitor
a lot of files that it didn't do in 0.9.1? 

I could try to install an inotify kernel to verify this but it may take me a
while as it looks like I have to compile my own kernel on Ubuntu. 

If this is the cause then perhaps something should be mentioned in the release
notes for the next version....
Comment 23 James "Doc" Livingston 2005-12-10 11:44:54 UTC
The code to monitor every directory that contain an imported track has been in
Rhythmbox for a while, but due to a bug it would only do that when you had just
imported files. The change is that we fixed the bug, so it monitors them all the
time. I've just looked and I have a pulse of 4% cpu usage (in the kernel) every
1/2 second, also with a non-inotify kernel.

I guess we could make the preference turn off monitoring all together, rather
than just not looking for new tracks.
Comment 24 Nicholas Allen 2005-12-10 12:34:18 UTC
I guess the CPU usage will be relative to size of library and processor. I have
a 1.4 GHz Centrino processor and a 60GB library.

It would be nice I think if all monitoring of the library could be automatic or
manual. In manual mode the user would have to explicitly ask rb to check current
status of files. The majority of the time my library doesn't change at all and
so checking every 1/2 second is overkill. But I guess if I have an inotify
enabled kernel there would be no polling at all and no CPU spikes...
Comment 25 James "Doc" Livingston 2005-12-10 12:40:57 UTC
Created attachment 55839 [details] [review]
patch to make it *really* optional

This will make the checkbox turn off monitoring completely. Note that weird
things will happen if you do something silly like replace one of your files
with a movie.
Comment 26 Sebastien Bacher 2005-12-10 17:51:39 UTC
Ubuntu linux packages have inotify by default and /dev/inotify is deprecated
Comment 27 James "Doc" Livingston 2005-12-11 10:23:30 UTC
Created attachment 55857 [details] [review]
fixed patch

Update of above patch, with all the possible monitoring-activate paths covered.
Comment 28 Mehmet Giritli 2006-02-16 19:34:13 UTC
I am using RB 0.93 on gentoo with gamin as the fam with inotify enabled kernel and regardless of the value of  the watch my library option in the preferences, gam_server continuously consumes above 20% cpu.
Comment 29 James "Doc" Livingston 2006-02-23 12:38:14 UTC
I've committed the patch to cvs, so if you turn off library-watching it will not monitor files at all. I'm leaving the bug open, since we should figure out why it is using so much cpu-time, and if there is something RB can do to reduce it.
Comment 30 Mehmet Giritli 2007-01-23 11:07:14 UTC
With 0.9.7 and kernel 2.6.19, this problem has disappeared for me...
Comment 31 Jonathan Matthew 2008-08-11 13:09:03 UTC
If anyone still has problems with file monitoring using excessive CPU time (or causing excessive I/O, I guess) with a gio-using version of rhythmbox, they are welcome to reopen this bug or open another.