[mythtv-users] Ceton Recorder [Was: Re: Announcement: merge of devel/027candidates]

[Jean-Yves Avenard]

On 18 May 2014 01:37, Jean-Yves Avenard <jyavenard at gmail.com> wrote:
> On 17 May 2014 23:21, Greg Thompson <gthompson20 at gmail.com> wrote:
>
>> OK, did a new Git clone, applied the patch you supplied, and so far so good… It appears to have fixed the issue. I will run it all day today to see if anything else pops up!
>>
>> Thanks for working throughout this with me!
>>
>> Greg
>
> Well, the Ceton is certainly not RFC2326 compliant, seeing that when
> it receives a KeepAlive packet on the TCP link it drops the
> connection... very silly
>
> Could you submit to me the output of the backend with -v record --loglevel=debug
>
> I want to see if I can be a tad smarter and detecting when to use keep
> alive and when not rather than having a special case for the ceton...

More specifically, what I want to see is if during the SETUP command,
when the server reply with a line Session: XXXXXXX

at the end of this line you have ;timeout=xx

If it doesn't I wonder if this patch would do the trick instead:

diff --git a/mythtv/libs/libmythtv/recorders/cetonrtsp.cpp
b/mythtv/libs/libmythtv/recorders/cetonrtsp.cpp
index 80a5b1a..7ec0212 100644
--- a/mythtv/libs/libmythtv/recorders/cetonrtsp.cpp
+++ b/mythtv/libs/libmythtv/recorders/cetonrtsp.cpp
@@ -24,7 +24,7 @@ CetonRTSP::CetonRTSP(const QString &ip, uint tuner,
ushort port) :
     _sequenceNumber(0),
     _sessionId("0"),
     _responseCode(-1),
-    _timeout(60),
+    _timeout(0),
     _timer(0)
 {
     _requestUrl.setHost(ip);
@@ -39,7 +39,7 @@ CetonRTSP::CetonRTSP(const QUrl &url) :
     _sessionId("0"),
     _requestUrl(url),
     _responseCode(-1),
-    _timeout(60),
+    _timeout(0),
     _timer(0)
 {
     if (url.port() < 0)
@@ -479,7 +479,7 @@ bool CetonRTSP::Teardown(void)

 void CetonRTSP::StartKeepAlive()
 {
-    if (_timer)
+    if (_timer || !_timeout)
         return;
     int timeout = std::max(_timeout - 5, 5);
     LOG(VB_RECORD, LOG_DEBUG, LOC +

I here simply assume that if the server doesn't explicitly announce
that it will timeout, then the recorder won't attempt to send
keepalive command.