From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Epiphany/1.3.8 Description of problem: My system slows to an absolute crawl when I rip cds with sound-juicer, now I understand that it's a CPU and IO heavy job, but other rippers do not slow my machine down to be pratically unusable. I found that renicing the process to 10 improved the situation, but that's just a hack-around. According to an earlier attempt at getting Bastian to look at this: http://bugzilla.gnome.org/show_bug.cgi?id=126467 He claims it's bad VM/IDE behavior, now if that is the case all my machines display this problem, and everyone I've talked to basically. I fear either Sound-juicer or gstreamer is causing this bad behavior, so in an effort to get this fixed so everyone can go back to enjoying their lifes and this fine piece of software. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Rip cd Actual Results: watch system pratically lock up, extremely high responsetime on any job. Expected Results: Relatively normal use of the system being possible. Additional info:
I don't think this bug has much to do with Fedora; we don't modify sound-juicer, and it doesn't have much to do with the OS in general except for our kernel. Particularly if other rippers work fine, that would suggest to me that it is an upstream sound-juicer issue. I've found a bug that seems similar to this, I'm moving this there. http://bugzilla.gnome.org/show_bug.cgi?id=116882
Since the post FC3 test2 update with the new sound-juicer and the new kernel the issue seems far less intrusive - now only CDs that are slightly damaged cause the system to become usuable for me. Did the new kernel enable DMA or something because I can't find any other explanation for this sudden improvement.