Thumbnail settings don't work as expected

gnome-video-thumbnailer is the culprit.
hda is also being hit to the tune of ~20MB/second.

confirmed in dapper.
there are some mp4 torrents to test with at http://media.ccc.de/filez/congress/2005/lectures/video/mp4/torrents/

Thanks for your bug. That's known upstream: http://bugzilla.gnome.org/show_bug.cgi?id=324656

The preference doesn't apply to video because it doesn't require to download the video to snapshot a frame

If you want to stop using the feature for a mimetype you can use gconf-editor and modify the "/desktop/gnome/thumbnailers/<mimetype>/enable" gconf key

i think the problem here is more to do with the thumbnail being remade every few seconds during a download. this results in almost constant processor usage during a download.

You can read bug #1573 which has been fixed on the topic. Is your download slow? Nautilus only start the mechanism after 5 seconds without any change so a slow download hanging could cause that sort of behaviour ...

the number was from bugzilla.ubuntu.com, that's bug #8329 on launchpad now

could that time be set to 10 seconds? that might help a bit.

or could nautilus take into account how recently the thumbnail was updated? for example if we have recieved more than 2 notifications on the last minute then set the timeout to 30 seconds

it could probably be smarter. 10 seconds would give the impression it doesn't work on "normal" situation (like a copy of an image that takes 1 second). Is your issue due to the fact than the download has no activity for 5 seconds or not?

i was downloading with gnome bittorrent client. its quite possible that there where lots of 5 second gaps with no new packets arriving. or is it possible that the gnome bt client caches the data, rather than streaming straight to disk?

maybe, I've not worked on bittorent nor looked at that code

From duplicate bug 150817:

Proposed solution: If a file has been modified previously in the last N seconds and has been modified again, do not attempt to thumbnail the file.

that's what the code is already supposed to do

"2005-05-08 Martin Wehner <email address hidden>

 * libnautilus-private/nautilus-thumbnails.c:
 (thumbnail_thread_start):
 Don't try to thumbnail files which have been modified in the
 last few seconds to avoid constantly re-thumbnailing them.
 Current cool-off period is three seconds. Fixes bug #107418."

upstream closed the bug with this comment

"In general its a bad idea to limit thumbnailing based on file size for most
non-image formats, because the size of the file does not generally indicate how
much you have to read or how much work you have to do to thumbnail it. So, a
500 megabyte pdf with 500 pages is likely as fast to thumbnail as a 1 megabyte
file with one page.

Therefore we do not artificially limit out-of-process thumbnailers. If a
particular thumbnailer requires it it can enforce the limits itself."

Doing the same on the distribution task there

Still getting this bug in intrepid. The cooling-off period of 3 seconds is not enough to avoid constant 100% cpu usage while downloading torrents with multiple videos and viewing them in a nautilus window.

This has nothing to do with file size, and everything to do with it being silly for the system to be bogged down continually be thumbnailing incomplete and constantly-changing video files. Surely there must be a way to avoid this, while still achieving expected behaviour when simply writing a file once. Bug #8329 mentions only thumbnailing once the file is closed, rather than on every change...?

don't reopen closed bugs if you have a similar issue in a new version but open a new bug