Red Hat Bugzilla – Bug 116498
gst-register uses 100% cpu when entering a folder with nautilus containing divX video
Last modified: 2007-11-30 17:10:37 EST
From Bugzilla Helper:
User-Agent: Opera/7.21 (X11; Linux i686; U) [en]
Description of problem:
(not shure if this is the rigth place to file the bug - if not,
please move it)
When I enter a folder (with nautilus) which contains divX video
files, i can see the cpu meter maxes out at 100%, and a short look
with "top" shows that a prosess named gst-register is to blame. when
i kill it, it goes back to normal (not showing up in top)
Version-Release number of selected component (if applicable):
gstreamer-tools-0.6.4-0.1 gstreamer-0.6.4-0.1 gstreamer-plugins-0.6.
Steps to Reproduce:
seen it on several macines. Can't tell if its only occuring on divx
video. I have installed mplayer, and said that .avi files should be
opened with gmplayer
Actual Results: cpu maxes at 100% until prosess is killed
Expected Results: maybe not trying to make a thumbnail of .avi
files? (if this is what it tries to do)
This is bizarre. gst-register should only be run by the
post-installation script of the rpm package.
Can you really reproduce this every time you enter a folder in
nautilus containing divx video? Are you sure it's gst-register?
I was able to reproduce every time it on my laptop. Going to check if
the bug's still there.
Yes, I am shure it was gst-register, as I checked with top. It looked
like it tried to index the folder.
Do you have any custom RPMs installed or is this all FC1?
Some of my RPM's is from freshrpm's (as I have used this as a way to
get faster download speeds (borowing network uplink from friends and
my school - I use ISDN at home, plus up2date is really buggy. Yes, i
know I can use YUM directly, but...) and ability to use synaptic), and
maybee som packages from livna (mp3-patched rhytmbox - didn't work.
Guess these are replaced with something from freshrpms by now.), pluss
some various sources (general software downloaded from the net. I
honestly don't remember everything).
Is there some log file etc. you would be interested in looking at? I
might even be able to forward the ssh port for you. Again, i'm on an
ISDN uplink and it will not be possible for me to fix that shell-thing
during the next few days (easter).
When checking, i see that the bug has mysteriously gone away (as far
as I can see - not any extensive testing done, but the bug was really
easily reproduced), and everything now works great.
If it occurs again then please reopen the bug.