Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090521 Shiretoko/3.5pre ID:20090521135222 With the following steps I'm constantly able to break the video playback of ogg videos in vmware machines like Ubuntu 8.10 and Windows XP SP3. Steps: 1. Load http://tinyvid.tv/show/3uwvr4t3wi3rm 2. Wait until the video has been finished loading 3. Click play 4. Drag the scrubber to the end of the video and hold it there 5. Wait a couple of seconds and drag it to the start of the video 6. Release it immediately After step 6 the status of the video is playing but it will never continue. On both machines the cpu load goes up to nearly 100%. In same situations the browser is locked completely so I can't interact with any element in content or chrome. The only way to get started the playback is to reload the page. Otherwise you can wait forever while the throbber is spinning all the time.

It also happens for local ogg videos. Download the mentioned video to your local harddrive, open it and do the same actions on it. In both cases it doesn't continue the playback.

I was able to create a screencast of this problem: http://screencast.com/t/9Jd2Qit5sm

I don't know if this problem can also arise on normal machines. I don't have a native Linux or Window box right now. Probably it will not block but lets get it on the radar.

Marcia, could you have test-runs in the lab if you are able to reproduce it?

(In reply to comment #3) > I don't know if this problem can also arise on normal machines. I don't have a > native Linux or Window box right now. Probably it will not block but lets get > it on the radar. What do you mean "normal machines"? What machines have you been able to reproduce this on?

I don't think we should block on this until we find it's reproducible with steps less complicated than reported.

I can't reproduce this in my Linux VM (SUSE 10.2). With a local video everything's fine, with the tinyvid video I can get a delay after step 6 but playback does resume eventually. Can you check if the patch in bug 494336 helps?

I have reactivated my locally installed Vista Bootcamp installation and wasn't able to see this issue. Now while playing around with a VM I found the problem. It manifests to be a VM only issue and will not happen with a native installation. Steps: 1. Click Play button 2. Drag the scrubber out of the VM window 3. Drop it there After step 3 the video doesn't get played anymore until you reload the page.

(In reply to comment #8) > Steps: > 1. Click Play button > 2. Drag the scrubber out of the VM window This should happen horizontally and directly over the pause button. Leave the window on the left side. > 3. Drop it there

A better screencast with a one step action: http://screencast.com/t/oHPjOb8Vbjl Do we think that we are in a dragging event and waiting for the drop action? As what I can see now is, that the playback will work after 30s-1min. Do we have a timeout for those an action?

Whimboo: you're saying it only happens in a VM? Dolkse: any chance the dragging it outside the window is causing oddness?

(In reply to comment #11) > Whimboo: you're saying it only happens in a VM? Yes. I can't repro this behavior when running this Vista version natively from my Bootcamp partition. (In reply to comment #7) > Can you check if the patch in bug 494336 helps? Roc, I have created tryserver builds but the patch on bug 494336 doesn't help here (https://build.mozilla.org/tryserver-builds/hskupin@mozilla.com-bug494316/)

This could be a problem with the control themselves.

I can't repro this on ubuntu VM. i tried the steps in the screencast, and when i move my mouse back over the video window, it resumes playback. Tested on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090521 Shiretoko/3.5pre

Roc, while verifying bug 469408 I noticed that I have massive problems with Linux builds (both Shiretoko and Minefield). Videos are stopped when I seek to another position. I cannot get them to play again and have to reload the page. That sounds somekind similar to the reported behavior in the former comments. Each reload of the page results in a fresh download of the video. I thought we have a media cache to store video data. Why don't we use the cached data? Shall I file this as another bug?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090522 Minefield/3.6a1pre Not sure if it is the same cause, and it's hard to reproduce, but I have had the CPU stick at 100% after dragging the scrubber on a <video>. This is on native Linux. Will try and get some more concrete STR.

Daniel, does the same happen with Shiretoko?

(In reply to comment #15) > Roc, while verifying bug 469408 I noticed that I have massive problems with > Linux builds (both Shiretoko and Minefield). Videos are stopped when I seek to > another position. I cannot get them to play again and have to reload the page. > That sounds somekind similar to the reported behavior in the former comments. Can you attach gdb and get stack traces for all threads? Find me on IRC and maybe we can work through this. > Each reload of the page results in a fresh download of the video. I thought we > have a media cache to store video data. Why don't we use the cached data? Shall > I file this as another bug? No. The media cache is only designed to cache data within a single load of the resource.

(In reply to comment #11) > Dolkse: any chance the dragging it outside the window is causing oddness? (In reply to comment #13) > This could be a problem with the control themselves. Maybe it's possible to make the scrubber think you're still dragging it and remain paused (bug 493508 added pause-on-drag), but the screencast shows repeated clicks on the play/pause button having no effect, not even changing the icon state. Since that all simple code, I'd suspect the video core is wedged and not responding / generating events. If you've got your own builds, you can set "debug" to true in videocontrols.xml and get some console logging.

This is the debug output after setting debug to true inside videocontrols.xml. As you can see the first seek events were handled successfully but with the last one no seeking has been started. Ok, probably because I already was at position 0 and dragged the scrubber to the left side. Justin, if there is nothing which helps you in identifying this problem, I'ld like to go the way from Roc and have a debug session with him.

Roc sent me patch which I used to build a tryserver build. It can be found here: https://build.mozilla.org/tryserver-builds/hskupin@mozilla.com-bug494316/ Running this build on Linux shows me that when dragging the scrubber out of the vm window we wait with continuing playback until the mouse has been placed inside the vm window. In between nothing happens.

Can you attach the log?

I hope that helps. Sadly we don't have timestamps for the debug output.

The video from step 1 is not there anymore. 404.

(In reply to Stefan Fleiter (:sfleiter) from comment #24) > The video from step 1 is not there anymore. 404. This bug is no longer actionable. Re-open if it is still an issue.