> I've now installed a new version (2012.10.18) of the "LIVE555 Streaming
> Media" code that incorporates (the equivalent of) your proposed fix. Please
> test it (in your > VLC client) to make sure that it works OK for you.
Thanks Ross, much appreciated. I will test it asap.
> You, however, are
Ralf,
I've now installed a new version (2012.10.18) of the "LIVE555 Streaming Media"
code that incorporates (the equivalent of) your proposed fix. Please test it
(in your VLC client) to make sure that it works OK for you.
BTW, I now understand why you saw this situation occur, but I never did.
Ralf,
Thanks for the note. Your patch looks like a good idea; it will likely be
incorporated into the next release of the software.
However, although your patch is a good idea (basically, a 'sanity check' for
the case when a '$'-framed packet is received without an appropriate handler
for the
Oops, you forgot to attach your patch.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
>>> Ross Finlayson 16/10/12 11:50 PM >>>
Apologies, the buggy mail software seems to have dropped the attached patch,
or at least I can't see it on the mailing list. Attempt #2.
Regards,Ralf
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and i
Hi Ross,
> So if you still see problems even with the latest version of the software
> (for both the server and client), then you're going to
have to track this down yourself. (Please don't bother sending 'wireshark'
logs; I never look at those.)
After upgrading the server, the issue persiste
> Could it be that once the client starts processing the RTP data i.e. before
> the 200 OK of the PLAY arrives, that the handler is then set to the $
> (RTP/RTCP handler) and that
> if an RTSP message comes in, even though it gets processed, it's
> callback/completion handler is not invoked sin
>> OK, your log suggests that 'incomplete' data is being received over TCP (by
>> the client), which implies (assuming that your client+server OS's TCP/IP
>> implementation is correct) that some of the server's writes to the TCP
>> socket are failing.
>
>
> The fact that this is happening woul
