mms:// radio crashes / was: Re: [MPlayer-users] divxa32.acm segfault (NOT a bugreport)

[Per Wigren]

Actually the mms-protocol seems to support seeking and ffw/rev on streams that 
are not live...  The initial server-response tells if the stream is live 
(multicasted) or not.

I also found the problem I had with mms://wmengine.spraydio.com/krakow ... 
After it has sent command 1e (which is documented by SDP as "end of stream", 
but I really think is "end of file" instead) it may send a command 20 (which 
is not covered by the document at all) which I guess means that a new file 
will follow, so the player should "restart" (without reconnecting) like it is 
the next song in a playlist...

// Wigren

Tuesday 22 October 2002 18.15 skrev Arpi:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hi,
>
> > > as no one of us is familiar with teh mms:// protocol 9actually it's a
> > > secret
> >
> > Get a reverse engineered doc from: http://sdp.ppona.com/
> > (http://sdp.ppona.com/MMSprotocol.doc)
>
> sorry i have no interest neither time to work on this.
> also it has legal issues i don't want to jump into now.
>
> > I have a personal interest, as mplayer seems to crash while attempting
> > to fastforward on a mms stream - or is that supposed to work?
>
> no, seeking in network streaming is not supported/implemented
> anyway if you have big enough cache, you can seek fwd/back a little bit
>
>
> A'rpi / Astral & ESP-team
>
> --
> Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
>
> _______________________________________________
> RTFM!!!  http://www.MPlayerHQ.hu/DOCS
> Search:  http://www.MPlayerHQ.hu/cgi-bin/htsearch
> http://mplayerhq.hu/mailman/listinfo/mplayer-users