> 1. Replies to HTTP GET requests are sometime truncated. As an example, > curl http://serverip/somets.ts will sometimes result in only part of the > playlist > > I've traced this to fNumBytesToStream is not being initialized when > created in handleHTTPCmd_StreamingGET, this caused doGetNextFrame to > sometimes ended prematurely.
Are you sure?? If you are referring to the "fNumBytesToStream" variable in the "ByteStreamMemoryBufferSource" class, then note that this variable is checked only if "fLimitNumBytesToStream" is set, and in that case "fNumBytesToStream" will always be set (see "ByteStreamMemoryBufferSource.cpp", line 55). I'm not saying that there can't be a bug in this code, but if there is, I don't think it's what you're describing. > 2. When streaming is in progress and client disconnected in the middle of a > transfer, mediaServer will keep trying sending to the disconnected client in > TCPStreamSink::processBuffer and will not respond to further requests. I don't see how that can happen, because the socket is non-blocking. If the client disconnects, then the call to "send()" should return (with less than the expected number of bytes written). At that point, the server won't try "send()"ing to the socket again until it becomes writable again (which won't ever happen if the client has disconnected). 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
