I see issues with zooming and video thumbnailing as well (on latest Hardy), the system becomes really slow. It may be a totem-thumbnailer bug, so CC-ing Bastien.

System becomes slow-ish, but it's working fine. The video thumbnailer has a cap on memory usage and CPU time, so it can only load for ~30 seconds before exiting.

If nautilus is eating the memory, and not totem-video-thumbnailer, then it's not a video thumbnailer problem.

Yep it does not seem to be directly related to totem. The process eating all the memory is nautilus.  The bug seems to occur if there is a thumbnailer available for video files (and if the zoom is > 100%)... Nautilus 2.22.2 just hit Debian/experimental and the bug is still there. 

I have created another user account and can still reproduce the bug.

Note that in my case the system is not "working fine". Once nautilus fills the available memory (1GB) and everything gets swapped to disk I'm lucky if I can open a terminal to kill it.

I confirm this bug. I have zoom = 150% in nautilus and this bug appears on any *.mkv file of decent size (cannot reproduce it on any *.avi file, though). Small files do not cause noticeable leak, seems it's somehow depend on file size.

It looks like this: file appears in directory, gnome-video-thumbnailer eats some cpu making its job, then movie thumbnail appears instead of standard videotape icon, and nautilus cpu usage begin to increase, as its memory consumption. If not killed, its residual memory goes up to all available, then virtual memory jumps up to 1 gib (I've got 1gib installed), everything else swaps out till system stops responding (leaving some oom-killer log records).

I tried to attach strace to running and leaking nautilus just before I killed it. First and last 15 lines of strace result can be found here:

http://launchpadlibrarian.net/12967338/nautilus-strace

Total number of lines was > 100k (19Mb file), while strace was attached only about 9 seconds!

Can confirm that too. System becomes very slow with very long response.

Ubuntu bug: https://bugs.launchpad.net/nautilus/+bug/222769

This a copy of my comment on the Ubuntu bug on launchpad :

I can confirm this bug and reliably reproduce it, after suffering from it for a long time seemingly randomly without understanding what caused it, and finally noticing a strange coincidence tonight (see below).

Also I can maybe tell why and how it happens by guesswork ...

=== Conditions to reproduce the bug ===
* nautilus in icon view, with thumbnails enabled,
* any video file for which nautilus has had a thumbnail generated

At this step the tentative conclusion is that the bug is related to video thumbnailing support, however the totem-video-thumbnailer program seems fine, and is not executed by nautilus when the bug happen anyway.

=== First method to trigger the bug ===
* Select the video file in a nautilus window or on the desktop
Symptoms:
* lots of disk accesses happen
* meanwhile nautilus' resident memory progressively increase by *exactly* the size of the video file, as reported by gnome-system-monitor (this is usually barely noticeable with small video files but gets problematic with 4GB ones ...)
* it then frees all the memory allocated during the previous step

* changing folder or closing the nautilus window during step 2 is generally enough to interrupt the process and make it restore the allocated memory prematurely.

That leads me to the tentative conclusion that nautilus is copying the file entirely in its memory, to do stuff with it. The question remaining is then what could that stuff be ?

=== Second method to trigger the bug ===
* increase the zoom level to over 150% (ie from 200% upward)
Symptoms:
* same as with first method, seemingly with each video file in the folder one at a time when there is more than one present

A few considerations:
* Thumbnails generated by totem-video-thumbnailer (the png files in ~/.thumbnails) are all 128px wide (the 'normal' size subfolder);
* at 100% zoom level, they are displayed by nautilus at width 96px, at 150% it's 128px wide.

* Nautilus does thumbnailing of image files internally (without calling an external helper like it does for videos), and also store 128px wide thumbnails for image files;
* when needed, ie when zoom level is over 150%, it automatically rereads image files to provide non-blurry thumbnails with higher resolutions, which it seems to only keep in memory (these do not end in ~/.thumbnails).

=== Conclusion: how the bug happen (plausibly) ===
* Nautilus has a routine for regenerating thumbnails of higher resolutions when zooming in, which for some reason is also called when simply selecting a file (as a preemptive step maybe ?)
* This routine works by copying all the content of the file to be thumbnailed into memory (which seems unavoidable for an *image* file)
*** the bug is here *** That routine is called by nautilus for all files which have a thumbnail, without checking the filetype first (silly nautilus)
* As a consequence, the entire video file is copied into memory, before nautilus (or maybe gdk-image-loader or whatever it's called) realize it doesn't know what to do with it and frees the memory.

As an aside this means one could theoretically reproduce this bug with files of any type, as long as they are thumbnailed (and not directly by nautilus like image files) and are large enough for the bug to be noticeable, however those conditions are only ever fulfilled in practice by videos.

This has been fixed before the Nautilus 2.28 release:

http://git.gnome.org/cgit/nautilus/commit/?id=a8097e57788ad735227489e6c51d06bedc796889


We could now backport this fix to the Nautilus 2.26 branch, but instead I wrote to the desktop-devel-list mailing list [1], asking whether there is some standard procedure for notifying all the distributors about this important patch, and suggesting to back-port it to all supported releases (including LTS).

[1] http://mail.gnome.org/archives/desktop-devel-list/2009-September/msg00147.html

Can someone close this fixed bug?

Closing.