<div dir="ltr">On Thu, Oct 24, 2013 at 2:51 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite">
<div dir="ltr"><div>1. Replies to HTTP GET requests are sometime truncated. As an example,</div><div>curl <a href="http://serverip/somets.ts" target="_blank">http://serverip/somets.ts</a> will sometimes result in only part of the playlist</div>

<div><br></div><div>    I've traced this to fNumBytesToStream is not being initialized when created in handleHTTPCmd_StreamingGET, this caused doGetNextFrame to sometimes ended prematurely. </div></div></blockquote><div>
<br></div></div>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).</div>
<div><br></div><div>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.</div><div class="im"><div><br></div></div></div></blockquote><div>
 </div><div>I missed the check on "fLimitNumBytesToStream". In this case, should "fLimitNumBytesToStream"  be initialized to False? It is some non-zero value when testing the code.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><div></div>
<div><br></div><div><blockquote type="cite"><div dir="ltr"><div>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.</div>
</div></blockquote><div><br></div></div></div>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).<span class=""><font color="#888888"><br>
<br></font></span></div></blockquote><div><br></div><div>Thanks for the clarifications, I've looked further and found that send() is returning -1, with errno being set to EPIPE. The problem is in "select" in BasicTaskScheduler::SingleStep still indicating a writable socket even when it is disconnected. Is this a libc problem? I'm working on Fedora 17 if that matters.</div>
<div><br></div><div><br></div><div>Thank you.</div><div>Park.</div></div></div></div>