I can confirm this behaviour.

It's linked to the file being created or refreshed and totem-video-thumbnailer continues to eat both CPU cycles and memory.

What's worse is that I don't use totem-video to view my avi's (I use vlc) and because totem can't open the file it basically get's pretty upset.

Is there any way to disable totem-video-thumbnailer?

I have run into this same problem on corrupt digital camera .mpeg files, and have found the cause of this bug.

In the file Filters/TagLib/Mpeg/File.cs function ReadVideoPacket() has an infinite loop if the first marker found is not a "Marker.VideoSyncPacket"  This is because the value "offset" never get incremented, and it keeps reading the same marker over and over and over...

Here is a version of that function which prevents and infinite loop:

void ReadVideoPacket (ref long position)
{
    Seek (position + 4);
    int length = ReadBlock (2).ToUShort ();
    long offset = position + 6;
    // Put a sanity limit on how long we search
    int sanity_limit = 1000;
    int i=0;

    while (!video_found && (i < sanity_limit) && offset < position + length) {
        if (FindMarker (ref offset) ==
            Marker.VideoSyncPacket) {
            video_header = new VideoHeader (this,
                offset + 4);
            video_found = true;
        } else {
            // Make sure we keep moving forward, because this one didn't match
            offset += 4;
        }
        i++;
    }

    position += length;
}

@Philip: which version of Nautilus and Totem are you using? To which package does the Filters/TagLib/Mpeg/File.cs file you mentioned?
Also, CC-ing Bastien for this.

Philip, the piece of code that you mention looks like that belongs to Beagle's taglib filter, which definitely isn't used in totem. File a separate bug against libbeagle for that.

As for the original problem, nautilus is supposed to back off when the file has been modified in the past 5 seconds. This can be a problem for bittorrent'ed files, as they might not get data within the past 5 seconds, but not be complete enough.

Furthermore, totem's video thumbnailer will only use 15 seconds of CPU time, or 30 seconds of total run-time, so as to avoid hogging the CPU in those cases.

My mistake.  I was attempting to report a bug in beagle.  I used the search to look for the bug before posting, and didn't realize the search results weren't limited to beagle bugs.

It seems this is still an issue with 2.24.

*** Bug 558136 has been marked as a duplicate of this bug. ***

I had the same problem and I found a temporary/quick solution. In nautilus, go to preferences, preview and set "show previews" to "never" for "other previewable files" (I am using gnome in a different language, so I am trying to guess the English versions). It will stop from nautilus/totem from creating thumbnails for all files but it will also stop them from eating up cpu when downloading videos. It has been confirmed to help (https://bugs.launchpad.net/ubuntu/+source/totem/+bug/79030)

*** Bug 570737 has been marked as a duplicate of this bug. ***

It's even simpler, I ran into this problem when I opened up two nautilus windows, and copied a large video file from one folder to another.

99% of the CPU was being used by totem-video-thumbnailer and tracker. The nautilus file copy operation ground to a halt and the file was hardly being copied until I closed the destination nautilus window.

[Bumping version as per comment 6.]

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.