[Live-devel] MilestoneXProtect playing problem

[Chris Richardson (WTI)]

Hi Ross,

 

I do understand what a process is and believe my definition to be the same
as most other people.  Regardless of that, I can tell you that if you set
'reclamationTestSeconds' to 0 that it does stop the server from killing
non-active client sessions, including those that have been closed in a
non-graceful manner.  Isn't this the expected behavior?  It is easily
reproducible, at least on my Windows XP PC, with testOnDemandRTSPServer and
openRTSP using the following procedure:

 

1.       Start testOnDemandRTSPServer

2.       Start openRTSP with the URL of the H.264 stream on the
testOnDemandRTSPServer instance

3.       Allow openRTSP to stream for a few seconds

4.       Kill openRTSP with Ctrl+C

5.       Verify the testOnDemandRTSPServer  instance is still (attempting
to) send data via the large amount of continuing console output

6.       Kill and restart the testOnDemandRTSPServer

7.       Run the same test as above but with VLC, and close the stream
gracefully in VLC using the stop command

8.       Verify that the server stops writing out console messages

 

I find it hard to believe that nobody else would be able to reproduce this,
given that the whole point of 'reclamationTestSeconds' is to handle the
above situation.  If we disable the reclamationTestSeconds feature by using
a value of 0, I would expect the server to behave exactly in that way.

 

Thanks,

 

Chris Richardson

WTI

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Tuesday, June 18, 2013 1:20 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] MilestoneXProtect playing problem

 

 

On Jun 18, 2013, at 8:39 AM, Chris Richardson (WTI) <chris at gotowti.com>
wrote:





That is correct.  You can verify the server will keep sending data for each
broken stream by simply killing the client process and restarting it. 

 

No, it doesn't do any such thing (unless the word "process" means something
very different for you than for everyone else :-)

 

In any case, this is now a moot point, because I have just installed a new
version - 2013.06.18 - of the "LIVE555 Streaming Media" that recognizes
incoming "OPTIONS" requests - with a "Session:" id - as indicating client
liveness (as you suggested).

 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130618/69a3183a/attachment.html>