nautilus uses 99% of cpu and responds very slowly

Thank you for your bug. What view mode do you use (colum or list? what zoom?)? Does it uses 99% of cpu until you stop it or just the time to display the directory?

it uses not exactly 99% (it can be 86 or so... equally bad)
i use list mode for "/" (but the windows are 'objects')
i tried /dev (690 items) - it takes more than 1.5 minutes and was not
finished. i killed it (system monitor window) and cpu goes down.

if i open /lib (129 items) then it takes approx 20 sec and it displays.
when even teh display part not visible is finished, then the cpu usage
goes down.

i tried on another partition (ntfs format, my root is ext3):
the same effect.

by the way beagle does not work on both of these partitions (it works
only on /home)

i hope this helps you to find the bug. thank you for your efforts!

andrew

Sebastien Bacher wrote:
> Thank you for your bug. What view mode do you use (colum or list? what
> zoom?)? Does it uses 99% of cpu until you stop it or just the time to
> display the directory?
>
> ** Changed in: nautilus (Ubuntu)
> Importance: Undecided => Low
> Assignee: (unassigned) => Ubuntu Desktop Bugs
> Status: Unconfirmed => Needs Info
>
>

--
ÐÏࡱá

what zoom level do you use? do you have the problem with another zoom or with the icon mode? what do you call "windows are 'objects'", do you use the spatial mode?

i installed feisty and still the same behavior after a clean install and no additional packages (except thunderbird); beagle was not installed!

folders with more than 600 entries do not open at all! if there are 100 to 200 files, then it opens but slowly. (and says "empty" for a long time before it says 'loading' - one could believe it and delete the empty folder)

i think this is an important issue and i am happy to help. i used the 'object' mode but are now back to spatial mode. the zoom level was 50%

i found a natilus log file, which was very large and had many entries which mentioned a problem due to "signal = 11"

unfortunately, i cannot find the log file anymore, so i cannot be more precise, but perhaps this is helping.

do you have gam_server running? do you use some NFS mounted drive?

i do not see gam_server as a process running and i did not intentionally install it.
i have nfs mounted partitions.

i attach the log file i found.

Could you get a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem.

I can confirm this running Feisty and using gnome-video-thumbnailer from totem-gstreamer 2.18.1-0ubuntu3. I don't think this is actually a "bug", meaning that nautilus&thumbnailer is doing what they are designed to do.

1. Azureus is loading a video file to a directory nautilus is watching.
2. Nautilus notices "oh, the file changed, better create a thumbnail for it".
3. Thumbnailer runs, and usually even creates a thumbnail successfully (.avi needs only the beginning and the end to be viewable in sane players, and those are the parts azureus tries to fetch first).
4. Go back to step 2 because the file has already changed.

The end result is that while the file downloads nautilus continually recreates the thumbnail wasting 100% of the CPU in the process (and this shouldn't have anything to do with azureus, the same ought to happen while downloading with any bittorrent client). Workaround is to download to a directory which is not watched, but some fix to nautilus would be nice, e.g., have some timeout before creating a new thumbnail for the same, changed file. This is probably the same as as bug #56738.

Sorry, I commented wrong bug :( Should have been to bug #79030.

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future.