Red Hat Bugzilla – Bug 466478
Videos start to crawl after some time
Last modified: 2008-10-24 16:32:11 EDT
When watching a video for over 30 minutes the video starts to crawl and freezes.
ps -A is not showing any processes that would hog the CPU. Neither there is any information about possible errors in /var/log/messages and Xorg.0.log. The system was updated to the latest rawhide version available on Thursday 09/10/2008. The same issue persists when I log out and log in into my desktop environment (Gnome). The system is currently using EXA. The same issue happens when I watch too many videos on webpages for a long time. The simply freeze. The sound is running fine and the whole system is responding.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 320086 [details]
Here is my Xorg.0.log. I don't use any xorg.conf file. Everything is automatically detected.
I'm affraid hat this issue is not intel driver related. I have found some suspicious messages regarding pulseaudio. I have removed the pulseaudio daemon and other related libraries and right now I'm running pure alsa. The problems with videos subsided. Can you assign this bug to the pulseaudio component?
I'm seeing this too. It seem to started happening with some of the post-f10-beta updates, or at least I haven't noticed it in beta. It's definitely a pulse audio problem for me - doing pulseaudio -k and restarting the applications gives me another nice 30 or so minutes before this happens again.
Similar problems arises with audio only application where rhythmbox simply stops playing. Retrying to play the song leads to rhythmbox starting it to play but not showing progress and dying shortly after.
The timings are pretty much same both for video and sound and it's always about 30-35 mins of active playing.
It definitely worked on F9 on the same hardware. Is there any useful info I could provide?
I suggest to have a look to bug 462200
Please retry with 0.9.13-4!
*** This bug has been marked as a duplicate of bug 462200 ***
(In reply to comment #6)
> Please retry with 0.9.13-4!
I noticed matthias' mail on the test-list and was going to report the results
after further testing, but so far it looks like this version fixes the issue
for me (but I have only a little more than an hour and half or so of testing).