gnome-video-thumbnailer uses all available CPU power when using bittorrent

[Thomas Folz-Donahue]

I don't know which package to put this under, as gnome-video-thumbnailer apparently doesn't have a package.
"
[eigenlambda@muon:~ ^_^]$ dpkg -S /usr/bin/gnome-video-thumbnailer
dpkg: /usr/bin/gnome-video-thumbnailer not found.
"

So when I download large video files using azureus, gnome-video-thumbnailer repeatedly tries to come up with a fitting thumbnail as the file is downloading. Naturally, this only happens when I download to the desktop, or some other folder that nautilus is watching (my guess is, nautilus watches directors and responds to every inotify event by checking the thumbnail of every file that's been modified).

[Michael Broadbent (mikebro)]

I believe this is a component of the totem package. If this is incorrect please change it.

[Sebastien Bacher (seb128)]

That file is an alternative, that's why it's not listed. Totem is used for video thumbnailing. What version of Ubuntu do you use? Do you use totem-gstreamer or totem-xine? Nautilus is supposed to try to thumbnail the video only if it didn't change for some seconds so it doesn't keep thumbnailing it. Does it happen with any video? Do you get the same problem if you run gnome-video-thumbnailer from the command line?

[Thomas Folz-Donahue (eigenlambda)]

Ubuntu Edgy, totem-gstreamer. The problem isn't that it tries to thumbnail repeatedly. The problem is that it fails because parts of the file are downloaded and parts aren't. And takes all available CPU power in failing. It would be nice if it didn't try thumbnailing bittorrent files, or didn't try thumbnailing anything that's downloading...

[Thomas Folz-Donahue (eigenlambda)]

oh yeah, my current solution: $ while sleep 3; do killall gnome-video-thumbnailer; done
Prevents it from wasting enough CPU to turn on my laptop's fan, anyway.

[Jarmo Ilonen (trewas)]

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 related to bug #56738.

[Paulus (donmatteo)]

Not sure why the importance is set to zero. This is a genuine bug: gnome-bideo-thumbnailer should never use 100% CPU for a prolonged period of time, no matter what the circumstances.

This bug is annoying, and comes up often when downloading video files into a folder and simultaneously viewing the folder in nautlius.

[Paulus (donmatteo)]

Of course I meant the imortance should be set to "normal", not to "low".

[unggnu (unggnu)]

I can confirm this for Feisty. This is not a Bittorrent problem. It is general since it happens for every video file which is downloaded at the moment and which is shown in Nautilus. I have this problem with DownThemAll (Firefox plugin) too and the Thumbnailer uses 100% CPU and lets my fan run very loud. The easy solution is to close Nautilus but I think this shouldn't be needed.

[unggnu (unggnu)]

BTW I don't think that this is a Totem problem. I think Nautilus is the app which starts gnome-video-thumnailer so it has to be fixed. Maybe Nautilus shouldn't create Thumbnails for videos/files which are in use (only writing, reading would be no problem).

[Sebastien Bacher (seb128)]

do you have a slow connexion or it stopping? Nautilus update the thumbnail only if the file has not been changed again in some seconds to avoid eating the CPU, if changes are made every 10 seconds the system doesn't work correctly though

[unggnu (unggnu)]

I have a 6 Megabit connection.
I have realized that it takes over ten seconds after opening the directory with the video download until the gnome-video-thumbnailer is started which consumes nearly all cpu time he can get. After some time the process exits which results in normal cpu usage for some time and then it starts again. This seems to be repeated until the download has finished.

[unggnu (unggnu)]

It seems that the same problem happens when copying huge video files to slow mediums like USB harddisks. Video-thumbnailer is started again if the target directory is open.

[Sebastien Bacher (seb128)]

that's not a gutsy target

[Götz Christ (g-christ)]

I can confirm this bug in Feisty. I think that is a Nautilus problem, and also the importance should be set to normal because it consumes the battery power of the laptops!

[Harald Schilly (harald-schilly)]

I can confirm this bug, too. I think the correct strategy would be to tell Nautilus to call the thumbnailer only, if there was no file change (including write access, because downloading software preallocates the file and doesn't alter it's length!) during the current view of the folder. pressing the reload button or changing the folder back and forth restarts possible thumbnailing actions, but doesn't repeat it all the time a file is being written to.

[Götz Christ (g-christ)]

Its very bad for laptop batterys to use 100% of the CPU all the time.
Is there any fix?

[VictorGreen (publicpolicywonk)]

I can confirm this bug with Gutsy 32bit. Im getting a video via aim file transfer on Pidgin. Its not continuously eating 100%, it just does so in spikes on one or both cores every 10-30 seconds and runs at 100% for another 10-30 seconds.

[Basilio Kublik (sourcercito)]

Hi there
Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the development branch of Ubuntu, Hardy Heron?

Thanks in advance.

[Paulus (donmatteo)]

Thanks for replying. I don't regularly use the program any more, so I
can't tell if it has disappeared. So, as far as I am concerned, you can
close the bug.

[Thomas Folz-Donahue (eigenlambda)]

Hi,

The problem here is that whenever a file is altered, Nautilus redoes its thumbnail. This is *usually* good behavior, but it is not good behavior for files that are being downloaded, because it wastes resources generating thumbnails that will then be thrown away.

I don't know if it has been fixed in the next version. Try downloading a video file, maybe a long speedrun from highspeedhalo.net or something, and see if it tries several thumbnails over the course of the download.

Thanks,
~thomas

[Sebastien Bacher (seb128)]

nautilus only thumbnail if the file has not changed for some seconds which means it should not trying to update a download thumbnails

[Thomas Folz-Donahue (eigenlambda)]

On Thu, Mar 13, 2008 at 6:21 PM, Sebastien Bacher <email address hidden> wrote:
> nautilus only thumbnail if the file has not changed for some seconds
> which means it should not trying to update a download thumbnails

I believe we have a report that this bug is fixed in the next version.
 By all means, then, close it.

~thomas
--
cartwheel ^(^_^)> v(.-.)v <(^_^)^

[Jarmo Ilonen (trewas)]

The bug still exists in hardy, or at least parts of it: thumbnails are recreated often for files which are downloaded. According to the upstream bug nothing has changed since 2005-05-08 and a steady stream of duplicates is still coming.

Even though nautilus updates the thumbnail only when the file has not been modified in a few seconds (3s according the upstream bug), at least with bittorrent there are often short breaks between writes because of buffering and the thumbnailer still gets often activated.

When the thumbnailer works ok, this does not cause too bad CPU waste, but occasionally with broken files (which is kind of normal state for incomplete files) it will waste all cpu for a while before giving up. This actually seems to be "fixed" in hardy, nautilus does not bother to try again if thumbnailer fails even once. As a result there is no cpu waste but often no thumbnails either, if nautilus was displaying the directory while the file was downloaded. I am not sure if that is intentional or not...

[emilio (emiliomaggio)]

I have recently updated to Intrepid and this problem is particularly bad. If I useAazureus when the download folder is open, my laptop becomes unusable. Same situation with Limewire. Probably this kind of continuous update is ok with multicore architecture. however in older machines and netbooks is a big problem.

[Wayne McDougall (ubuntu-codeworks)]

Agree with emilo. A serious problem with Intrepid. I'm using Transmission.

[Gargamel (spamcatcher-free)]

Hi all,

Running under Debian Lenny (Gnome 2.22.3) since a few time, I got it too. 100% of the cpu when transfering divx to usb Hdd drive.

[iponeverything (cookema)]

The same is happening with me -- Intrepid + Transmission

until a cure is found:

 mv /usr/bin/gnome-video-thumbnailer /usr/bin/gnome-video-thumbnailer.no

[Gustavo Rahal (gustavo-grahal)]

IMO this is a fairly important bug as download of video files to desktop is a very common desktop user operation. If a user is using the computer while it's downloading a video it will make the whole desktop experience suffer and user won't understand why.

[Gustavo Rahal (gustavo-grahal)]

Just noticed that severity of the bug is set to major in gnome bugzilla although the priority is set to normal. The bug is open since 2003 so I believe people watching this bug in launchpad should also add comments to gnome bugzilla as it's where the bug has a chance to be fixed.

[kvncylmz (kvncylmz)]

Hi everybody, it seems it has been nearly three weeks since last post, I don't know the current situation, however, 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 names)

But I am using: opensuse 11.1, nautilus 2.24.1, so my solution might not apply to everybody. In that case, updating gnome/nautilus might help...

[Daniele Varrazzo (daniele-varrazzo)]

Thank you for this tip. The bug is still there (Intrepid).

[kvncylmz (kvncylmz)]

You are welcome.
I have to note, however, this is a problem with gnome, not ubuntu or suse, so it might be better to check http://bugzilla.gnome.org/show_bug.cgi?id=430043
(just found)

[ressletr (ressletr)]

I did go into nautilus and turned off thumbnailing. However there is a better solution. Where are you downloading your videos to? Probably Desktop which constantly refreshes thus making the gnome-video-thumbnailer trigger off constantly. Try moving your download folder to another location. I just loaded transmission and noticed it was saving my downloads to the Desktop.

[kvncylmz (kvncylmz)]

Well, I believe you are right in the sense that if the folder to which you are downloading the video is currently open/visible, the thumbnailer tries to update the thumbnail and go crazy. Therefore if you are downloading to a folder which is not visible, the problem will probably not occur. As a result, if you always remember to download into some folder which is not open now, you should not face this issue.

[emilio (emiliomaggio)]

My experience is that this bug affects all the folteds as long as their nautilus window is open.

[peter (peter--s)]

Hi,

I'm using Intrepid and get the same bug when I download videos from my video-cam in kdenlive (with firewire). Since a new .dv file is produced for every scene kdenlive detects (typically 5 to 20 seconds) I get easily some hundred .dv-files.
The title of the files is something like "capture131.dv" and I'd like to see the thumbnail to be able to identify the scene without opening it in totem.

- That means, that the bug has nothing to do with the way how the movie was moved to the computer (Bittorrent, Firewire, ...)

- I get the nearly 100% of CPU usage only if i open the folder with the files with nautilus.
- If I wait until all files are thumbnailed, everything is fine (even with the opened folder).

- Filesize doesn't seem to matter for gnome-video-thumbnail since the .dv-files are typically not very large (around 20 MB), but the thumbnailing process still takes around 10 s for every file. (for 200 scenes=files this makes still more than half an hour of 100% CPU usage).

I think, there is real issue (not only an inconvenience for thumbnailing large movies) because 10 s of thumbnailing for a 5 MB file is not really a good performance.

[mlissner (mlissner-michaeljaylissner)]

I'm a little disconcerted that this bug has been around for so long, and yet that it is still marked as low priority. Sure, it's not a crasher, but any application that is using 100% CPU is a big problem, in my opinion.

The solution for this seems pretty obvious and easy to program. I wonder if we can get it nominated for the 100 papercuts, or somehow get it triaged for the next release?

[abhiroopb (abhiroopb241088)]

I am having the same problem using Transmission or downloading a file from firefox. I think this has been happening for a while, but it is only recently that I realised what it was.

[Stefano Prenna (stefanoprenna)]

I can confirm this bug in Jaunty. Downloading files on the desktop is enough to recreate the issue.

[Stefano Prenna (stefanoprenna)]

Applying the instructions at: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/187136/comments/5 that allow the usage of totem-xine for thumbnail instead of totem-gstreamer actually works.

Obviously this doesn't solve the issue, but I think it's a good workaround for those people that have this problem 2007 and never had a solution...

[Alex Ruddick (alexrudd0)]

Still present in karmic.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

I am assigning this to nautilus since the upstream bug is also assigned to nautilus.

[karlrt (karlrt)]

why changing status to invalid? what do you need to be triaged?

[Sense Egbert Hofstede (sense)]

This bug has not been marked as Invalid. However, the task for Totem has. This is because it has nothing to do with this bug. As you can see on the top of this page there are still two tasks open: one for Nautilus in Ubuntu and one for an upstream bug report.

[pascal germroth (pascal-germroth)]

also, it's still not fixed in lucid.

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

Nearly crashed my entire computer. Window borders were killed, top panel died, RAM usage flew threw the roof. This bug hit me very hard.

[Everthon Valadão (valadao)]

Good news! The new option of adding a .part suffix at incomplete downloads,
included in the newer version of Transmission bittorrent client, indirectly
helped me with this bug: the thumbnails aren't regenerated anymore.

But this bug still exists: gnome-video-thumbnailer should wait some bigger
interval before updating the thumbnails, not doing it at every single second
for every file of the folder. Speaking of it, here is an idea:
gnome-video-thumbnailer should generate thumbnails only for the files
visible on the current nautilus view, i.e. only the files listed by the
current scroll bars position.

Everthon Valadão
http://www.dcc.ufmg.br/~evaladao

On Fri, Jun 11, 2010 at 3:25 PM, Chauncellor <email address hidden>wrote:

> Nearly crashed my entire computer. Window borders were killed, top panel
> died, RAM usage flew threw the roof. This bug hit me very hard.
>
> --
> gnome-video-thumbnailer uses all available CPU power when using bittorrent
> https://bugs.launchpad.net/bugs/79030
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[funicorn (funicorn)]

Same here. I noticed high cpu possesion happens when thumbnailing some video file which is incomplete or broken,
such as the file being downloaded but unfinished by BT software.

[inverser (resrevni)]

Can't elaborate on the cause, but Gnome-video-thumbnailer (GVT) was running out of control (95-99% CPU usage) on my Core2Duo system. I was able to correct the behavior by turning off the download speed limitation I had placed on an episode of Battlestar Galatica, which was downloading in Transmission. GVT went back to normal immediately thereafter. I was not able to reproduce because I can't seem to figure out what caused GVT to go haywire in the first place.

Ubuntu 10.10 (maverick)
Kernel Linux 2.6.35-23-generic
Gnome 2.32.0

[kate (learner)]

I fixed it making a little script that disable executable rights before i start downloading videos/files and i restore executable rights when i fisish downloading.