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've finally come around to try to dig deeper into this reconnect issue. First, I'd like to point out that I've updated to the latest liveMedia code (2012.09.13) and I've redesigned my program to only access/create liveMedia objects/functions within a function triggered by triggerEvent(). I put some debug messages in RTSPClient::sendRequest(), but it doesn't seem to end up there when I do the seek. I do get an exception at random locations. Sometimes it happens without me doing anything, i.e. directly when the connection has been re-established, other times the exception occurs after I try to do something to the RTSP stream, e.g. stop or seek. Below is an example of the call stack for an exception: ... msvcr90d.dll!_free_base(void * pBlock=0x61d4d496) msvcr90d.dll!_unlock(int locknum=4) msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0) msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0) msvcr90d.dll!_free_base(void * pBlock=0x05051718) msvcr90d.dll!strerror(int errnum=111825400) RtspVideo.dll!BasicUsageEnvironment0::setResultErrMsg() RtspVideo.dll!readsocket() RtspVideo.dll!RTSPClient::incomingDataHandler() RtspVideo.dll!BasicTaskScheduler::SingleStep() RtspVideo.dll!BasicTaskScheduler0::doEventLoop() ... here is another one: ... msvcr90d.dll!malloc(unsigned int size=21) msvcr90d.dll!operator new(unsigned int size=21) RtspVideo.dll!BasicTaskScheduler::SingleStep() RtspVideo.dll!BasicTaskScheduler0::doEventLoop() ... Please let me know what I can do to help. I'll continue to look in to this. Again, what I do is: 1. Play an archive (i.e. non-live) stream. 2. Unplug Ethernet cable. 3. Do a seek while disconnected. 4. Plug in Ethernet cable. I get an exception every time, but as mentioned above, it appears slightly different and the call stack usually looks different each time. /Claes
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
