main track list/view is very obtrusive when files are being added/removed

[steubens]

Binary package hint: rhythmbox

if you add a whole bunch of songs at once, or remove a volume with a lot of songs on it while rhythmbox is open; and you have the top "All x artists" selected in the multicolumn view; the software only removes and updates the main list at a rate of a song or 2 per second (and uses 100% cpu), if you pick any one of the artists in the column view while its doing this (as such, viewing all from one artist, or album), it will do 100s a second due to the fact that it will not update the list for that selection until it changes, this applies to all column views

secondly, in an attempt to stay on top of this you might pick the first artist on the list; and until it is removed with the volume it will be fast, but the moment it is it will return to the "All x y" label in the multicolumn view; so you have to babysit it if you don't want it to use 100% cpu while it removes songs

ProblemType: Bug
Architecture: amd64
Date: Sat Feb 27 01:13:45 2010
DistroRelease: Ubuntu 9.10
Package: rhythmbox 0.12.5-0ubuntu5.2
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-20.57-generic
SourcePackage: rhythmbox
Uname: Linux 2.6.31-20-generic x86_64

[Pedro Villavicencio (pedro)]

Thanks for the report, I'm not getting such issue here with Lucid , I've an external disk with more than 10000 songs and the issue is not present here, could you please test the same on lucid and comment back? Thanks.

[steubens (steubens)]

yes, it still does it with beta 2; the main view redrawing for every new item is what makes it very slow

if you've ever added the folder to rhythmbox and it sees the device go away; it will add all of them at once when it comes back (thus bypassing what i described), you'll want to purge ./.local/share/rhythmbox/rhythmdb.xml (though there are other ways to make it do it, this is simplest)

as i said in the original post; picking a less often updated folder in one of the column views during the add stops it from using 100% cpu; additionally it is able to add songs much faster, as it redraws _the entire main view_ for every song if you pick the "All" entry at the top of the column views

[Launchpad Janitor (janitor)]

[Expired for rhythmbox (Ubuntu) because there has been no activity for 60 days.]

[steubens (steubens)]

this is still going on, rhythmbox guys don't care either, most of the time is spent in the video driver; but only because the treeview is updated so often

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Oneiric Ocelot. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[steubens (steubens)]

yes it still happens; it's due to the murrine theme and the maintainer of rhythmbox doesn't even really acknowledge it as a problem

(there was a similar cpu usage problem with transmission, ubuntu has had patches in the past for it and iirc still does in 11.04)

[Walter Garcia-Fontes (walter-garcia)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running apport-collect <bug #> and any other logs that are relevant for this particular issue.

[Launchpad Janitor (janitor)]

[Expired for rhythmbox (Ubuntu) because there has been no activity for 60 days.]