>> By the way, I think there might be a bug in the handling of the
>> periodic liveness commands:
> No, the periodic ‘liveness’ commands are intended to test that the TCP
> connection is still alive, and also to compensate for a large number of
> servers that require these periodic commands in te
Thanks. From this I was able to figure out the bug in our proxy server code,
and have now installed a new version of the “LIVE555 Streaming Media” code that
should fix it.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel ma
> By the way, I think there might be a bug in the handling of the
> periodic liveness commands:
> If an OPTIONS response is never received,
> ProxyRTSPClient::continueAfterLivenessCommand is never called, and the
> next liveness command will never be scheduled.
No, the periodic ‘liveness’ commands
> OK, I still can’t quite figure out what’s going wrong here, but I think I’m
> getting closer. I’ve just installed a new version (2016.03.16) of the code
> that adds some extra checking, and some more ‘internal error’ debugging
> fprintf()s. > Please run this new version, and let me know if yo
> What would be a good way to modify the proxy server such that:
> 1. The connection to a proxied server is torn down and setup again if
> the server is not sending any data
> 2. The connection to a proxied server is torn down and setup again if
> there is a mismatch between "Session" expected by t
> OK, I still can’t quite figure out what’s going wrong here, but I think I’m
> getting closer. I’ve just installed a new version (2016.03.16) of the code
> that adds some extra checking,
> and some more ‘internal error’ debugging fprintf()s. Please run this new
> version, and let me know if y
OK, I still can’t quite figure out what’s going wrong here, but I think I’m
getting closer. I’ve just installed a new version (2016.03.16) of the code
that adds some extra checking, and some more ‘internal error’ debugging
fprintf()s. Please run this new version, and let me know if you see any
>> I still don’t know how/why this can occur, but I’ve just released a new
>> version (2016.01.24) of the code that adds some ‘INTERNAL ERROR’ messages if
>> the queue gets into an inconsistent state. Should you see any of these
>> messages, please let us know.
>>
> I noticed one of the prints
2016-01-24 22:22 GMT+01:00 Ross Finlayson :
>> On Jan 12, 2016, at 1:48 PM, Erik Montnemery wrote:
>>
>> I'm using the live555ProxyServer to be able to reliably record and view
>> streams from four cheap cameras concurrently.
>> Recording is done in 15 minute chunks with 15 seconds of overlap, me
> On Jan 12, 2016, at 1:48 PM, Erik Montnemery wrote:
>
> I'm using the live555ProxyServer to be able to reliably record and view
> streams from four cheap cameras concurrently.
> Recording is done in 15 minute chunks with 15 seconds of overlap, meaning
> there will normally be between 4-8 acti
Thanks for the report. At first glance, I can’t figure out why this is
happening, but I’ll keep it in mind. (If anyone can provide more details about
what/how this is happening, please let us know.)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_
I'm using the live555ProxyServer to be able to reliably record and view
streams from four cheap cameras concurrently.
Recording is done in 15 minute chunks with 15 seconds of overlap, meaning
there will normally be between 4-8 active clients for the 4 proxied streams.
The live 555 version is 2015.1
12 matches
Mail list logo
