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?

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.

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

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.

Created attachment 55617 [details] [review]
patch to make monitoring optional

This patch adds a checkbox to turn off monitoring.

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?

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.

patch committed to cvs

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.

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

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.

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.

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

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.

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

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.

This should (hopefully) be fixed now.

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. 

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

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.

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.

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

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.

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

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.

Ubuntu linux packages have inotify by default and /dev/inotify is deprecated

Created attachment 55857 [details] [review]
fixed patch

Update of above patch, with all the possible monitoring-activate paths covered.

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.

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.

With 0.9.7 and kernel 2.6.19, this problem has disappeared for me...

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.