mplayer gets confused when playing avi from web and getting the whole file in response to a "Range" request.

[mplayer@…]

It I have an .avi file on a (slightly weird, but AFAIU not completely
non-conformant) web server that:

• Would advertize "Accept-Ranges: bytes" in its HTTP response header.
• Does not actually support it and would send the whole file in response to a

"Range: ..." HTTP request
then mplayer gets confused when being pointer to that .avi URL.

Namely, it would loop, sending repeated HTTP requests with various "junk" (even
negative at times) "Range: ..." headers.

P.S. Once the server is fixed to send "Accept-Ranges: none", the problem goes away.

P.P.S. The server that send the wrong "Accept-Ranges:" header is gallery2
(​http://www.gallery2.org/), I've filed an RFE to fix it at
​http://sourceforge.net/tracker/index.php?func=detail&aid=1495690&group_id=7130&atid=357130

[mplayer@…]

Output of "mplayer -v -v -v URL.avi"

[reimar]

AFAIK this is not fixable, since IIRC when MPlayer sees accept-ranges it tries
to read the index at the end of the file to allow seeking - which obviously
cannot work in such a case (or does the server indicate that it starts sending
data from the beginning? Then a minor improvement might be possible).
You could also try the -noidx switch, maybe it helps.

[mplayer@…]

(In reply to comment #2)

or does the server indicate that it starts sending data from the beginning?

It definitely does. When it sends the requested partial data,

• The HTTP status code is 206 (Partial Content) - see

​http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.7

• The HTTP response header includes the Content-Range field thast specifies

what exactly was returned (according to the specs, this field MUST be present in
any "206" response). This is the header that tells what was actually sent, so it
would be nice if mplayer paid attention to it. See
​http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16

When the server sends the complete file,

• The HTTP status code would be the usual 200 (OK) instead of 206
• There would be no Content-Range header.