[Live-devel] Re-connection handling

[Erlandsson, Claes P (CERLANDS)]

There is one case where it doesn't work though, and I'm not sure how to
handle it. This is if I do a seek while the stream is disconnected, then it
never reconnects. In some cases I play a 10s loop where a timer do a seek
every 10s and jumps back (using absolute seeking). Those streams never
reconnect after a disconnection.

 

 

OK, so unless you can tell me a reliable way to reproduce this problem
(perhaps using "openRTSP), then you'll need to figure out yourself why the
LIVE555 library's connection reestablishment code is not working in this
case (and then I'll try to fix it).  Remember, You Have Complete Source
Code.

 

The place to look in the code is near the start of
"RTSPClient::sendRequest()" (line 535 of "liveMedia/RTSPClient.cpp").  When
you do your 'seek' (really "PLAY") operation (that's failing), then is
"fInputSocketNum" <0?  If so, then what value does "openConnection()"
return.

 

If, however, "fInputSocketNum" is >= 0 (in practice, it will be >0), then we
will (eventually) call "send()" (at line 787) to transmit the command.  Is
this "send()" call succeeding, or not?

 

 

I don't believe there is a loop functionality in openRTSP, so I can't think
of a way to recreate it there.

 

In simple words, what I do is:

1. Play a non-live stream.

2. Pull the plug on the server side (shouldn't matter if client side
though), and put it back.

3. Do one, or many, seek (PLAY-command using absolute time) on the stream
while not connected.

4. When connection works again, the stream will not continue, while other
streams will.

 

I will do some testing and look up the lines you're referring to. Will get
back when I've some answers for you.

 





I see a few alternatives:

 

No, there's only one 'alternative': Figure out why the LIVE55 code is
(apparently) failing in this case, so I can fix the problem.  Trying instead
to work around this problem yourself might help you in the short term, but
wouldn't help anyone else.

 

I of course totally agree on that. Guess I considered that it potentially
could be a known issue that was hard to fix.

 

/Claes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120831/b72df890/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5740 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120831/b72df890/attachment.bin>