Closed
Bug 493511
Opened 16 years ago
Closed 14 years ago
Video playing get stuck when the network connection drops and then reconnect.
Categories
(Core :: Audio/Video, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: BijuMailList, Unassigned)
References
Details
Attachments
(1 file)
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
Comment 1•15 years ago
|
||
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
Comment 2•15 years ago
|
||
Eugene, it sounds like the problem you're seeing is a variant of bug 526411.
Comment 4•15 years ago
|
||
> 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.
Comment 5•14 years ago
|
||
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
Comment 6•14 years ago
|
||
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?
Comment 8•14 years ago
|
||
(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?
Comment 9•14 years ago
|
||
It is a very short duration video, so needs to be disconnected immediately after pressing PLAY button
Comment 10•14 years ago
|
||
(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.
Comment 11•14 years ago
|
||
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).
Comment 12•14 years ago
|
||
(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?
Comment 14•14 years ago
|
||
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.
Description
•