Description of problem: Wiped F7, installed F8, kept my home directory from F7. Moved old ~/.gnome* and ~/.gconf* directories out of the way and let F8 create new ones. I have a directory 'music' with 15 GB of mp3 and ogg files in it. The Rhythmbox in F8 refuses to find all of the files in that directory. Using either 'watch library' or 'import directory', Rhythmbox only goes through 2.2 GB of the files and then seems to think the job is done and stops. Version-Release number of selected component (if applicable): rhythmbox-0.11.3-3.fc8 gnome-vfs2-2.20.1-1.fc8 glib-1.2.10-28.fc8 glibc-2.7-2 kernel-2.6.23.8-63.fc8 How reproducible: Always Steps to Reproduce: 1. Remove ~/.gnome2/rhythmbox 2. Start Rhythmbox 3. Import a large directory of music files Actual results: Not all music files are imported. Expected results: All music files should be imported. Additional info: The file names in my music directory are in iso-latin-1 (I guess, made with easytag) and many of them contain non-ascii characters. This has not been a problem for previous versions of Rhythmbox.
Could you please attach the output of "rhythmbox -d" showing that Rhythmbox can't load those files?
Created attachment 289764 [details] output of rhythmbox -d when attempting to import the entire 15 GB library Debug log from trying to import the music library. The resulting rhythmdb.xml is in the following attachment. It does not have all the files that R attempts to index according to this log.
Created attachment 289765 [details] rhythmdb.xml (created by the same run as the log in previous attachment)
Attached a log and the database created. The files that do not get into the db do appear in the log. E.g. all music by Kent is scanned but does not go into the db file. I do not quite see what the problem is from the log.
Comment on attachment 289764 [details] output of rhythmbox -d when attempting to import the entire 15 GB library Update filename, it's doubly-compressed for no reason.
Comment on attachment 289765 [details] rhythmdb.xml (created by the same run as the log in previous attachment) And another one.
You're getting an awful lot of "failed to go to PAUSED for ..." messages in the log. Please test with gstreamer and gstreamer-plugins-base 0.10.15 from updates-testing. If that still fails, please attach the output of: gst-launch-0.10 -t urisrc location=file:///home/mhuhtala/music/omd/liberator/10_Best%20Years%20Of%20Our%20Lives.mp3 ! decodebin ! fakesink
I gzipped the attachments _once_ on my machine before uploading. I have the original files to prove it; they were not gzipped twice. Does Bugzilla gzip text attachments automatically? Updating gstreamer-plugins-base does not help. I now have mhuhtala localhost:~ > rpm -qa | grep gstreamer gstreamer-tools-0.10.15-1.fc8 gstreamer-0.10.15-1.fc8 gstreamer-plugins-ugly-0.10.6-1.fc7 gstreamer-plugins-bad-0.10.5-2.fc8 gstreamer-plugins-base-0.10.15-1.fc8 gstreamer-plugins-good-0.10.6-6.fc8 gstreamer-python-0.10.8-2.fc8 Bad & ugly are from freshrpms. Indexing still only finds 386 files out of 1980. The suggested command gives a 'does not want to pause' error (I could not get the urisrc thing to work so I used filesrc): mhuhtala localhost:~ > gst-launch-0.10 -t filesrc file:///home/mhuhtala/music/omd/liberator/10_Best\ Years\ Of\ Our\ Lives.mp3 ! decodebin ! fakesink Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. FOUND TAG : found by element "id3demux0". title: Best Years Of Our Lives artist: Orchestral Manoeuvres In The Dark album: Liberator date: 1993-01-01 track number: 10 track count: 12 duration: 277000000000 FOUND TAG : found by element "apedemux0". replaygain track gain: 0.090000 replaygain track peak: 0.710986 ERROR: from element /pipeline0/filesrc1: Internal data flow error. Additional debug info: gstbasesrc.c(2099): gst_base_src_loop (): /pipeline0/filesrc1: streaming task paused, reason error (-5) Setting pipeline to NULL ... FREEING pipeline ...
Remove gstreamer-plugins-ugly, or update it to something recent. It should work then.
Removing gstreamer-plugins-ugly does indeed get rid of the problem, by not indexing or playing mp3s at all. Brilliant. A quick look around shows that freshrpms, livna and Dag Wieer's repo are all at 0.10.6 or older. I use mythtv and therefore atrpms, which does not have gstreamer plugins. I'd like other repos in my config to be at least somewhat compatible with atrpms, so I wouldn't like to test them all and find out the conflicts the hard way. Oh well, the joys of third-party repositories. At least they all seem to be joining each other... or something.
I use dripple and livna. YMMV. Not my problem though...
Neither dribble nor livna has mythtv and the upcoming rpmfusion will not include atrpms... well, I probably shouldn't watch tv anyway. I was wondering what you meant by 'something recent' and only then realized that freshrpms had not recompiled the F7 package for F8 at all. I got rid of installed freshrpms and switched to livna. Now Rhythmbox works correctly. Let's see how many conflicts with atrpms I will run into. So this is a freshrpms incompatibility and should be closed as 'notabug'? The whole thing kinda makes me think not nice thoughts about the 3rd party repo situation. The bug was pretty cryptic, since a lot of the mp3s were indexed and played correctly, so it seemed as if the codec was ok.
The bug is in the 3rd party package, which has a bug. I can't help with that, and it's closed as NOTABUG, because it's the closest I can get for NOTFEDORASPROBLEM.