Slow Copy

[Guillaume Pascal]

Binary package hint: rhythmbox

I try to extract a cd in my library (.mp3) but the problem is that the copy is too long (34% of first track in 5 minutes)

ProblemType: Bug
Architecture: i386
Date: Sun Jan 24 23:38:32 2010
DistroRelease: Ubuntu 10.04
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/rhythmbox
InstallationMedia: Ubuntu-Netbook 10.04 "Lucid Lynx" - Alpha i386 (20100113)
Package: rhythmbox 0.12.6-1ubuntu6
ProcEnviron:
 LANG=fr_FR.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-11.15-generic
SourcePackage: rhythmbox
Uname: Linux 2.6.32-11-generic i686

[Jamal Fanaian (jamalta)]

I am able to replicate this issue with Rhythmbox. When I try to import a CD it goes terribly slow (it got to 3 songs in about 20 minutes) and starts using up all my CPU. In comparison, I tried importing with Banshee and it imports rather quickly. I was able to import the same CD in about 5 minutes.

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

[spamoften (spamoften-deactivatedaccount)]

What is the duplicate bug number?

[spamoften (spamoften-deactivatedaccount)]

Used TOP with "show threads" option to display the rythmbox threads during extract.

The top most CPU bound thread was priority 20 (the nice level for background threads) using ~30% of a CPU core (my laptop is 1.5Ghz dual core Intel x86).

The top IOWait was 0.

Therefore, the process was likely neither CPU or disk bound.

I noticed that the BOINC background worker threads were getting significant CPU time, so I hit "pause" to stop background processing of workloads. This therefore left completely idle CPU on my computer.

Afterwards, the extract performed more quickly, but was still not using 100% CPU or causing IOWaits.

iostat reported no IOWait, similar to top.

In conclusion, it is likely the thread design of the background threads is using a far too agressive "nice" setting and should be bumped up in both priority and IO nice level so that the extract takes advantage of the available hardware.

It should be obvious that if a user has deliberately clicked on a button to extract a CD, they would prefer that operation take precedent over other background tasks on the computer which they have not necessarily performed a manual and specific action to perform (BOINC is a good example).

[spamoften (spamoften-deactivatedaccount)]

Found the gnome bug:

https://bugzilla.gnome.org/show_bug.cgi?id=580565

[spamoften (spamoften-deactivatedaccount)]

My mistake, here is the original bug from 2006 still labelled unconfirmed in Rhythmbox.

There are dozens forum posts in google search on this item all redirecting people to use alternative programs to rip CDs.

https://bugzilla.gnome.org/show_bug.cgi?id=358770

[spamoften (spamoften-deactivatedaccount)]

No change after upgrading to Ubuntu 10.10, very poor extract performance.