From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: Importing even small collections of oggs/mp3's can take hours. It goes to 100% cpu and stays there, not knowing what to do. Version-Release number of selected component (if applicable): Rhythmbox 0.8.8 How reproducible: Always Steps to Reproduce: 1. Music->Import Folder 2. Select a main folder (top of tree) Actual Results: RB just hangs there, pretending to import more titles, though no more are being added, meanwhile it's hit a 'tree stump' and won't ever do anything useful again. Expected Results: Anywhere from minutes to days later, all the contents of the directories would be integrated into the library. Additional info:
Update: The importation is stopping on directories holding "album_art.gif" files. If I remove them, it proceeds. Every time. Suggestion: inform the import system to look for only .ogg/mp3/etc files _or_ have it ignore .jpg/.gif/etc files. Aye?
> Suggestion: inform the import system to look for only .ogg/mp3/etc > files Does not work. For example I have a directory with only mp3 files (121 in that particular case). rhythmbox imports some 18 of these, apparently in random, not even from a begining or end of a listing, and it goes into a deep funk. Doing strace shows that it loops continuously like that (this is on x86_64 for a change so this is not i386 specific): ..... poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}], 4, 0) = 0 write(3, "5\20\4\0U\r@\2.\0@\2\245\1\30\0;\3\5\0002\0@\2\0\0\0\0"..., 376) = 376ioctl(3, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}], 4, 34) = 0 ioctl(3, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}], 4, 36) = 0 ioctl(3, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}], 4, 61) = 0 ioctl(3, FIONREAD, [0]) = 0 ..... and there is even no way to break that wankery. It seems that the last resort is "Quit" on the menu but this is causing rhythmbox to seize up completely (no refresh, no reaction and a window stuck) with the following in strace: futex(0x684584, FUTEX_WAIT, 19, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x684550, FUTEX_WAKE, 1) = 0 futex(0x706434, FUTEX_WAIT, 1, NULL) = 0 futex(0x6face0, FUTEX_WAKE, 1) = 0 futex(0x706434, FUTEX_WAIT, 3, NULL and that is never finishing. What will load and what not is hardly predictable. On some directories with music files (they indeed are, I can play them) rhythmbox will import these and in others it will find nothing. Even if some of these files are corrupted, which can happen, this is hardly a good reason for such behaviour.
A new version, possibly inspired by bug 139293, fixes this. That'd be gathering newer versions from DAG's and Gstreamer, per the instructions. I'm now able to import the whole thing. Thanks, guys!
> A new version ... You mean packages in URLs given by that? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139293#c5 Contrary to what $basearch use could suggest repositories at gstreamer.freedesktop.org are i386 only. I could try some recompilation once I cleared other items from a long TODO list. :-)
Yeah, once I'd gone to bed (I'm on third shift) I realized you'd need more info; sorry... Packages: [brian@aquila ~]$ rpm -vq rhythmbox gstreamer gstreamer-tools gstreamer-plugins rhythmbox-0.8.8-2.1.fc3.rf gstreamer-0.8.8-0.fdr.1.3 gstreamer-tools-0.8.8-0.fdr.1.3 gstreamer-plugins-0.8.6-0.fdr.1.3 The DAG line: [dag] #name=Dag RPM Repository for Fedora Core #baseurl=http://apt.sw.be/fedora/$releasever/en/$basearch/dag # name=Dag APT Repository baseurl=http://dag.freshrpms.net/fedora/$releasever/en/$basearch/dag/ http://dag.atrpms.net/fedora/$releasever/en/$basearch/dag/ http://ftp.heanet.ie/pub/freshrpms/pub/dag/fedora/$releasever/en/$basearch/dag/ enabled=1 gpgcheck=1 (The commented lines are what I _used_ to have there) Do you need anything else?
Sounds like the original reporter got this bug fixed by updating to 0.8.8. That version is in FC4 (and later versions in FC5). FC3 is now the responsibility of Fedora Legacy, and this doesn't sound like a security bug. Closing.