[Live-devel] Logging or debug info

[Jan Ekholm]

On 7 maj 2014, at 21:28, Ross Finlayson <finlayson at live555.com> wrote:

>> Based on what I see it seems as if Live555 does not properly clean up the first session when the
>> connection breaks. Instead it seems to close the wrong connection when the time out occurs.
> 
> No, based on your description I'm not seeing any incorrect server behavior.  The server is timing out the first connection (and deleting the "RTSPClientConnection" object) 65 seconds after you kill the first client (without having it send a "TEARDOWN").  The second client then causes a new "RTSPClientConnection" object to get created.  (It happens to have the same address - 0x10c008000 - as the old "RTSPClientConnection" object, but it's a new object.)
> 
> The reason why the server stops streaming to the second client after the first client has timed out is most likely due to a problem with your own additions to the server - i.e., either your own "OnDemandServerMediaMediaSubsession" subclass, and/or your own "FramedSource" subclass.
> 
> First, when your "OnDemandServerMediaMediaSubsession" subclass's constructor calls the "OnDemandServerMediaMediaSubsession" constructor, then make sure that the "reuseFirstSource" parameter is "True".  This ensures that - if two or more clients request the stream concurrently - then your "FramedSource" subclass (i.e., your data source class) will be created only once.
> 
> Second, you must allow for the possibility of your "FramedSource" subclass object being closed, then recreated - perhaps multiple times.  If you set "reuseFirstSource" to "True" (as noted above), then you will never see your "FramedSource" subclass constructor being called more than once before the destructor is called - but you may see "constructor", "destructor", "constructor", "destructor", etc.  Your "FramedSource" subclass's constructors and destructors must allow for this to happen.
> 
> Finally, if you want to test the behavior of your server, then you should first do so using our "openRTSP" client (note the "-t" option to request RTP/RTCP-over-TCP streaming), not with some random other client (that might use a different - perhaps broken - RTSP client implementation).  Similarly, if you want to test the behavior of your own client, then you should first do so using "testOnDemandRTSPServer" or the "LIVE555 Media Server" as the server.  This is common sense.  If you want to test a client-server combination, then start with one combination that you know works OK ("testOnDemandRTSPServer" with "openRTSP"), then change only one end at a time as you continue your testing.

I can not reproduce the same problem when using openRTSP or testOnDemandRTSPServer.  My own client also behaves ok. 
I'm at a total loss as to what in my server code could cause only TCP to misbehave. I've spent enough time trying to debug that and
must move on for now. I hope to find the problem later when I get more familiar with Live555, it's not an easy library to use. 
I'm sorry for the time I've wasted for all readers.

One thing I did notice however that causes testOnDemandRTSPServer to freeze is to do like this:

1. start testOnDemandRTSPServer and stream something (in my case a H264 file)
2. start openRTSP #1 against the server
3. start openRTSP #2 against the server
4. suspend #1 through C-z to simulate a bad network connection
5. #2 will now not get any more data and the server is totally frozen until #1 is resumed


-- 
Jan Ekholm
jan.ekholm at d-pointer.com