When reconnecting within a few minutes of a disconnect with no other connected players, our server sends an End of Stream signal. This is allowed in the spec and every player except Mplayer is handling it correctly.
Looking at the mplayer source code, they are not parsing the End of Stream packet properly:
http://msdn.microsoft.com/en-us/library/cc251288%28v=prot.10%29.aspx
You can test that mplayer does not handle End of Stream + Stream Change (server side playlists) with this url: http://vmc001.sjo.edgecastcdn.net/serverside_playlist.wsx
When WMP plays this url it cycles through 4 on-demand files in progression. With mplayer, it plays the first item and reports a chunk error. This is the same scenario we are seeing with Live streams when reconnecting in a 5 minute window.
I'm not sure if this is a bug or missed feature in mplayer or possible legally protected functionality.
The error is:
>Ahhhh, stream_chunck size is too small: 4
>Error while parsing chunk header
This comes from the mplayer source, asf_streaming.c:
static int asf_streaming(ASF_stream_
chunck_t *stream_chunck, int *drop_packet ) {
...
}
In this code, they check the length of the chunk. If the length is less than 8, they throw the error above. Unfrotunately, the specification says this packet/chunk will always be 4 bytes in length (hence the error - stream_chunck size is too small: 4). Changing that check from 8 to 4 might fix the problem but I am not able to confirm that.
The bytes of the End of Stream (or $E) packet are 24 45 04 00 01 00 00 00
Packet length is the third and fourth byte (04 00) in network order.
PacketLength (2 bytes): This field MUST be set to 4.
The reason code are the next 4 bytes - 1 in this case to indicate that a Stream Change (or $C) packet will be sent next.
I encourage the customer to look at the mplayer source code or inquire within the mplayer forums or mailing lists. We have been working with Microsoft to attempt to reduce the 5 minute window but they are out of suggestions.