It is a response to a get parameter. The response is a 404 Not found with a
content-length of 316
But live555 doesn't read the 316 bytes length body of the response.
So when the library is reading again the socket, it reads the body of the
previous response, and doesn't find \r\n\r\n, so it blocks
I will second that. I have seen this same problem in an RTSP client stack
provided by a company whose name I will not mention.
On Mon, Feb 22, 2010 at 5:26 AM, Sébastien Escudier <
sebastien-de...@celeos.eu> wrote:
> Quoting Ross Finlayson :
>
> > Perhaps the server is (erroneously) ending its r
Quoting Ross Finlayson :
> Perhaps the server is (erroneously) ending its response only with
> \r\n, and not with \r\n\r\n ?
No,
The response is correctly ended by \r\n\r\n. The body isn't (but that's normal).
It is a response to a get parameter. The response is a 404 Not found with a
content-le
> If you can track this down some more, please let us know.
Ok, so the client is blocked in RTSPClient.cpp -> getResponse1 line 2191 in a
readsocket call.
The comment in the file says :
// Keep reading data from the socket until we see "\r\n\r\n" (except
// at the start), or until we fill u
On Wed, Feb 17, 2010 at 7:57 AM, Sébastien Escudier <
sebastien-de...@celeos.eu> wrote:
>
> > If you can track this down some more, please let us know.
>
> Ok, so the client is blocked in RTSPClient.cpp -> getResponse1 line 2191 in
> a
> readsocket call.
>
> The comment in the file says :
> // Ke
> If you can track this down some more, please let us know.
Ok, so the client is blocked in RTSPClient.cpp -> getResponse1 line 2191 in a
readsocket call.
The comment in the file says :
// Keep reading data from the socket until we see "\r\n\r\n" (except
// at the start), or until we fill up
In certain circumstances, the library is blocked on a select call.
The call stack is [1].
I think it occurs when the library tries to open a stream which is
being closed
at the same time
That shouldn't be happening, because everything runs in a single
thread. In each place in the code where
Hi,
In certain circumstances, the library is blocked on a select call.
The call stack is [1].
I think it occurs when the library tries to open a stream which is being closed
at the same time, but I am not sure because I can't reproduce this easily.
To test this case, I added a 30 seconds timeout
