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. 4-0.1.fr How reproducible: Didn't try 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) Additional info:
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.