0

I have created a http webserver which needs to support streaming video to other applications. I am facing issue with windows media player while seeking. Windows media player crashes when I seek in a particular fashion. Other than this it is working fine.

Steps in which media player is crashing.

Suppose there are 3 points on seek bar(say A, B, C).

1) A is the start position of video.

2) Jump to position C.

3) Jump back to position B.

4) Again jump back to position C(or any position ahead of position B).(This is where media player crashes with following error.)

"Windows Media Player encountered a problem while playing the file".

When the media player crashes, I don't get any request on my web server. otherwise on my server side I am getting normal seek(content-range) http requests.

Last Http request and response exchanged with media player on jumping to point B.

Request:

GET XXXXXXXXXXXXXXXXXXXXXXXXX HTTP/1.1
Connection: keep-alive
Cache-Control: no-cache
Pragma: getIfoFileURI.dlna.org
Accept: */*
Range: bytes=10125312-16437247
User-Agent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514
GetContentFeatures.DLNA.ORG: 1
TransferMode.DLNA.ORG: Streaming
Host: localhost:16716

Response:

HTTP/1.1 206 Partial Content
Date: Fri, 08 Mar 2013 11:41:54 GMT
Content-Type: video/mp4
Access-Control-Allow-Origin: *
Connection: keep-alive
TransferMode.DLNA.ORG: Streaming
File-Size: 33994175
Accept-Ranges: bytes
Content-Range: bytes 10125312-16437247/16437248
Content-Length: 6311936

Thanks

vijay053
  • 822
  • 3
  • 18
  • 36
  • Great, I'm going to post it as an answer then. Please accept it :) –  Mar 08 '13 at 16:21
  • I had somewhat the same problem: Content-Length was longer then the requested range (as was the sent data) – Zaibot Jul 30 '14 at 12:58

1 Answers1

4

This problem likely results from the invalid Content-Range header in your response.

The response specifies a File-Size: 33994175 header but your Content-Range header says something different: 

Content-Range: bytes 10125312-16437247/16437248

The range component following the slash (/16437248) should reflect the full size of the underlying resource in bytes. I suspect that windows media player takes that to mean there is no content after the 16437248 position and borks.

Changing the header in question to the following should solve the problem:

Content-Range: bytes 10125312-16437247/33994175
  • I am sending these headers(TransferMode.DLNA.ORG: Streaming and few more related to DLNA) in the response. Are they really required. Because if I don't send them, then also it is working fine!! – vijay053 Mar 12 '13 at 06:25
  • @user1187575 They don't have any meaning in the HTTP protocol and I'm not familiar with them. Any client that correctly implements HTTP should work just fine without them. If you don't know what they're for I wouldn't bother to keep them. –  Mar 12 '13 at 06:30