After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 430043 - Eats 100% CPU thumbnailing incomplete video
Eats 100% CPU thumbnailing incomplete video
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: Thumbnails
2.24.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 558136 570737 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-04-15 17:08 UTC by Crispin Flowerday (not receiving bugmail)
Modified: 2021-06-18 15:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Crispin Flowerday (not receiving bugmail) 2007-04-15 17:08:44 UTC
If you download a video over something like bittorrent, then nautilus can eat 100% CPU attempting to thumbnail the video. It is not repeatedly thumbnailing the video, it attempts just the once to thumbnail the video, and sits there in the thumbnail thread attempting to create the video (e.g. this is not the same issue as bug 107418)
Comment 1 Anoth 2007-08-27 16:22:47 UTC
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?

Comment 2 Philip Van Baren 2008-07-11 19:57:05 UTC
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;
}


Comment 3 Cosimo Cecchi 2008-07-14 23:36:44 UTC
@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.
Comment 4 Bastien Nocera 2008-07-15 09:29:15 UTC
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.
Comment 5 Philip Van Baren 2008-07-15 12:31:52 UTC
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.
Comment 6 Cosimo Cecchi 2008-11-02 12:22:01 UTC
It seems this is still an issue with 2.24.
Comment 7 Cosimo Cecchi 2008-11-02 12:22:10 UTC
*** Bug 558136 has been marked as a duplicate of this bug. ***
Comment 8 Kıvanç Yılmaz 2009-01-11 13:59:13 UTC
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)
Comment 9 Cosimo Cecchi 2009-02-06 01:03:50 UTC
*** Bug 570737 has been marked as a duplicate of this bug. ***
Comment 10 Mark D. 2009-08-01 21:46:50 UTC
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.
Comment 11 André Klapper 2011-08-11 18:57:37 UTC
[Bumping version as per comment 6.]
Comment 12 André Klapper 2021-06-18 15:15:38 UTC
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.