Closed Bug 493511 Opened 15 years ago Closed 14 years ago

Video playing get stuck when the network connection drops and then reconnect.

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: BijuMailList, Unassigned)

References

Details

Attachments

(1 file)

testcase to be PASSED
2.34 KB, text/html
Details 
Video playing get stuck when the network connection drops and then later gets reconnected.

1. Keep your network connection window ready
  (so that we can disconnect fast)
2. goto a page with a long video in Firefox
   eg http://media.tinyvid.tv/d3h9ycgenax0.ogg
   at http://media.tinyvid.tv/d3h9ycgenax0
3. ASAP, click play button on the video control
4. disconnect network connection
5. wait till the video play till it stops
6. wait for another 30sec
7. reconnect network connection
8. try clicking start/stop button on video control

Result:
Video never plays, or show any indication that connection was/is broken


Expected:
Video should show "X" when network connection broken and
play automatically when the network connection is reestablished.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre)
Gecko/20090517 Minefield/3.6a1pre
I see similar problem with Firefox 3.5.6 on Ubuntu amd64, and no need to disconnect even: if the connection is slow enough, and (theora) video plays faster than it is downloaded, when it plays up to the end of already downloaded segment of the file, playback stops and never resumes no matter what. Slider indicator shows that the file is being downloaded (up to the end), but pressing play/pause and moving the slider does not restart playback.

Chrome player resumes playback by itself when more data arrives, and this is likely the desired behavior.

See also https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/450684
Eugene, it sounds like the problem you're seeing is a variant of bug 526411.
> it sounds like the problem you're seeing is a variant of bug 526411
Quite probable: for me, playback is stuck after Play/Pause as well.
I observed the problem with firefox & Fennec [Ubuntu & Maemo]. 

OnStopRequest is not called when the connection drops. This problem happens only  during the buffering. html5 Player plays till the buffered data & gets stuck. No network error indication.

I would like to work on this issue, if I get some inputs. Because I'm very new to networking stuff.

Thanks
After network connection is dropped, I can see the general polling calls: OnStartRequest/OnStopRequest. (I think this is general network status check)

nsHttpChannel::OnStopRequest [this=0xb0233360 request=0xae78d8d0 status=804b0048]

status=804b0048 - NS_ERROR_PROXY_CONNECTION_REFUSED (804B0048)

But there is no OnStopRequest msg for MediaStream channel which is opened for the video.

Note: I'm checking behind proxy & code base mozilla-central
Sounds like opening a new connection fails but existing connections don't detect the connection drop.

Check with netstat whether the TCP connection still open? It probably is, which means it doesn't have keepalives (or the keepalive interval is too long), so it simply never detects that packets aren't getting through.

However --- are you actually seeing this bug? I mean, if you get back on the network, does the download resume?
(In reply to comment #7)
> However --- are you actually seeing this bug? I mean, if you get back on the
> network, does the download resume?

It resumes playback after reconnection.

But, I checked it on the Google Chrome. It gives out an Network error & it doesn't resume afterwards on reconnection.

So, I would like to know which is the desired behaviour?
Attached file testcase to be PASSED — 
It is a very short duration video, so needs to be disconnected immediately after pressing PLAY button
(In reply to comment #7)
> Check with netstat whether the TCP connection still open? It probably is, which
tcp        0      0 172.21.22.60:60842      172.16.42.137:http-alt  ESTABLISHED 2562/firefox-bin
> means it doesn't have keepalives (or the keepalive interval is too long), so it
> simply never detects that packets aren't getting through.
If playback resumes after reconnection, then I'd say this is irrelevant to *this* paticular bug, and is, generally, the expected behavior.

On a "classic" UNIX system, applications are not expected to "notice" when an IP interface goes down. (On modern desktop unii equipped with dbus and networkmanager they can notice if they want to).
(In reply to comment #11)
> If playback resumes after reconnection, then I'd say this is irrelevant to
> *this* paticular bug, and is, generally, the expected behavior.
Yes, I agree with you. Then how does user know that the connection is dropped?

Resuming playback also seems good. But user looks for some kind of notification when the connection is dropped.
I'm leaning towards declaring this bug FIXED as originally filed and INVALID as adjusted in comment #5.

I don't see a clear reason why we should treat "server stopped sending us data" differently from "network interface temporarily down" in the video element UI. Anyone got one?
For me, the symptoms as described in the original report where caused by the same problem as Bug 526411, and went away when that bug was fixed. I'd suggest to mark this bug duplicate of 526411, and the reporter of comment 5 to open a separate ticket.
I agree. Marking FIXED by comment 526411.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: