Bug #4499

SAT>IP: Fix five different bugs

Added by DSA APF 27 days ago. Updated 17 days ago.

Status:AcceptedStart date:2017-07-24
Priority:NormalDue date:
Assignee:Jaroslav Kysela% Done:

100%

Category:SAT>IP
Target version:-
Found in version:master Affected Versions:

Description

Hi Jaroslav,

After a lot of testing and debugging, we are glad to publish a fix for some SAT>IP server bugs.
We present the patches divided into 5 groups for a better understanding. In fact, the more relevant fix is the last one, but we present them in reverse order.

1) Add default short DESCRIBE:

At this time, when a session has incomplete configuration data or the delivery system is unsupported, in this case the session description is incomplete. This patch implements a short/neutral response. This is required by some clients that refuse to continue if the response is incomplete.

--- a/src/satip/rtp.c
+++ b/src/satip/rtp.c
@@ -811,7 +811,9 @@ satip_status_build(satip_rtp_session_t *rtp, char *buf, int len)
       c2tft, ds, plp, specinv, pids);
     break;
   default:
-    return 0;
+    // Send a short description (required by some SAT>IP clients)
+    r = snprintf(buf, len, "ver=1.0;src=%d;tuner=%d,%d,%d,%d,,,,,,,,;pids=%s",
+        rtp->source, rtp->frontend, level, lock, quality, pids);
   }

   return r >= len ? len - 1 : r;

2) Fix for incorrect delivery system in SESSION:

With the current implementation, when a new session is created the delivery session is not set correctly. Only the value for the MUX is set, but not the value in the SESSION.

--- a/src/satip/rtsp.c
+++ b/src/satip/rtsp.c
@@ -562,6 +562,7 @@ rtsp_start
                            &rs->dmc, 1);
       if (mux) {
         created = 1;
+        dmc = ((dvb_mux_t *)mux)->lm_tuning;
         rs->perm_lock = 1;
       }
     }
@@ -1109,6 +1110,7 @@ rtsp_parse_cmd

   dmc->dmc_fe_freq = freq;
   dmc->dmc_fe_modulation = mtype;
+  dmc->dmc_fe_delsys = delsys;
   rs->delsys = delsys;
   rs->frontend = fe;
   rs->findex = findex;

3) Fix incorrect Frontend & Source values in the DESCRIPTON:

The current implementation generates incorrect values for the feID and srcID in the description responses (for both, the RTCP header and for the DESCRIBE request). As documented in the “3.5.11 Query Syntax” section of the SAT>IP Standard Specification these values start with “1” and not “0”. The range for feID is [1..65535], and the range for srcID is [1..255]. It’s very easy to check the values generated by the TVH using the tcpdump command. Currently, “src=” and “tuner=” are often equal to “0”. The problem is in the initialization of the RTP queue. The call to the “rtp.c@satip_rtp_queue()” function has incorrect call parameters when called from “rtsp.c@rtsp_start()”. Furthermore, the current code uses three values: frontend, frontend-index, and source. However, only two are defined in the standard. The provided patch is sufficiently tested and it uses frontend-index and source as the parameters for creating the RTP stream. In addition, the initialization of the frontend-index is set to 1 instead of 0.

--- a/src/satip/rtsp.c
+++ b/src/satip/rtsp.c
@@ -626,7 +626,7 @@ pids:
                     &hc->hc_fd_lock, hc->hc_peer, rs->rtp_peer_port,
                     rs->udp_rtp ? rs->udp_rtp->fd : hc->hc_fd,
                     rs->udp_rtcp ? rs->udp_rtcp->fd : -1,
-                    rs->frontend, rs->findex, &rs->dmc_tuned,
+                    rs->findex, rs->src, &rs->dmc_tuned,
                     &rs->pids,
                     ocmd == RTSP_CMD_PLAY || oldstate == STATE_PLAY,
                     rs->perm_lock);
@@ -881,7 +881,7 @@ rtsp_parse_cmd
    session_t **rrs, int *valid, int *oldstate)
 {
   session_t *rs = NULL;
-  int errcode = HTTP_STATUS_BAD_REQUEST, r, findex = 0, has_args, weight = 0;
+  int errcode = HTTP_STATUS_BAD_REQUEST, r, findex = 1, has_args, weight = 0;
   int delsys = DVB_SYS_NONE, msys, fe, src, freq, pol, sr;
   int fec, ro, plts, bw, tmode, mtype, gi, plp, t2id, sm, c2tft, ds, specinv;
   char *s;

4) Fix response with a remote SAT>IP server returning BAD SERVICE:

This is a very obscure bug. The problem occurs when you use two instances of the TVH. One is the local server and the second is the remote server. When a client requests for a MUX to the local server, and the remote server responses with a 405-STATUS NOT ALLOWED (or a similar error), in this case the client never receives an error. Therefore, the client only continues after its timeout expires. The solution is recheck for every client request if the associated subscription is invalid. This is the way it works, since the asynchronous coupling between the SAT>IP server and client process inside the TVH makes it impossible to send back the response from the remote server. Fortunately, all SAT>IP clients resend the tuning command after a short period of time when the signal is unlocked. This patch fixes this problem with a very simple implementation.

--- a/src/satip/rtsp.c
+++ b/src/satip/rtsp.c
@@ -573,6 +573,12 @@ rtsp_start
               (rtsp_muxcnf == MUXCNF_REJECT || rtsp_muxcnf == MUXCNF_REJECT_EXACT_MATCH ) ? " (configuration)" : "");
       goto endclean;
     }
+    if (mux && rs->subs && rs->subs->ths_state == SUBSCRIPTION_BAD_SERVICE) {
+      dvb_mux_conf_str(&rs->dmc, buf, sizeof(buf));
+      tvhwarn(LS_SATIPS, "%i/%s/%i: subscription fails because mux %s can't tune",
+              rs->frontend, rs->session, rs->stream, buf);
+      goto endclean;
+    }
     if (rs->mux == mux && rs->subs)
       goto pids;
     rtsp_clean(rs);

5) Fix SETUP with STREAM parameter:

This is a definitive patch for resolve the problem described in #4474. Two questions are addressed in this patch:

a) The generation of a new stream identifier is restricted only to cases when it is necessary. For example, when a new SETUP command is received without a stream parameter. Or when a new subscription is created without a corresponding stream id. Additionally, the code now verifies that the stream value starts with “1” and not “0”. Therefore, each time the stream value at the end of the “rtsp_parse_cmd()” function is less than 1 a new identifier is created... and only in this case! So, in the case of a SETUP command with a stream parameter the received stream id is then reused.

b) The second problem is the behaviour of the RTP queue when a SETUP with a stream parameter is received. In this case, the stream must be in play when the signal is locked. Furthermore, and related to the previous fix (4), it’s required to not close the current session in case of receiving the same SETUP request. Only when the SETUP targets a new session, the current session assigned to the stream id must be closed.

This patch then replaces the burden solution described in #4474.

--- a/src/satip/rtsp.c
+++ b/src/satip/rtsp.c
@@ -964,7 +964,11 @@ rtsp_parse_cmd
         goto ok;
       }
       *oldstate = rs->state;
-      rtsp_close_session(rs);
+      /* At this point a SETUP cmd with a STREAM parameter is received,
+         only close the current session if the new request is different! */
+      if (freq != rs->dmc.dmc_fe_freq) {
+         rtsp_close_session(rs);
+      }
     }
     if (cmd == RTSP_CMD_SETUP) {
       r = parse_transport(hc);
@@ -980,6 +984,11 @@ rtsp_parse_cmd
     }
     rs->frontend = fe > 0 ? fe : 1;
     dmc = &rs->dmc;
+    if (stream > 0) {
+      /* At this point a SETUP cmd with a STREAM parameter is received,
+         so enable the play data flag! */
+      *oldstate = STATE_PLAY;
+    }
   } else {
     if (!rs || stream != rs->stream) {
       if (rs)
@@ -1127,10 +1136,16 @@ rtsp_parse_cmd
   rs->old_hc = hc;

   if (cmd == RTSP_CMD_SETUP) {
+    if ((stream > 0) && (rs->stream < 1)) {
+      rs->stream = stream;
+    }
+  }
+  if (rs->stream < 1) {
     stream_id++;
     if (stream_id == 0)
       stream_id++;
     rs->stream = stream_id % 0x7fff;
+    tvhinfo(LS_SATIPS, "new stream-id generated (%d)",rs->stream);
   }
   rs->src = src;

We have tested all of these patches, and hope that they will be commited.
Regards,
D.

Associated revisions

Revision ca308e0a
Added by Jaroslav Kysela 26 days ago

satip server: add short DESCRIBE, fix incorrect delivery system, fix frontend and source in DESCRIBE, fixes #4499

Revision debe129a
Added by Jaroslav Kysela 26 days ago

satip server: try to fix the stream/session mismatch, fixes #4499

Revision 4ee77e12
Added by Jaroslav Kysela 24 days ago

satip server: signalize pernament 'no data' state to rtsp layer, fixes #4499

History

#1 Updated by Jaroslav Kysela 26 days ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

#2 Updated by Jaroslav Kysela 26 days ago

  • Status changed from Fixed to Accepted

Applied 1-3. I need think more about 4 and I tried to resolve the SETUP/PLAY states in another way - https://tvheadend.org/projects/tvheadend/repository/revisions/debe129a49d90570f485e262ed0d21dede87b831 .

#3 Updated by DSA APF 25 days ago

Jaroslav Kysela wrote:

Applied 1-3. I need think more about 4 and I tried to resolve the SETUP/PLAY states in another way.

Dear Jaroslav,

Thank you!
We will test your solution for the issue 5 with some clients. We will keep you informed.

Regarding the issue 4, we will be happy if you implement a better solution. However, keep in mind that our patch is fairly simple and it can’t disturb any current implementation. Therefore, we suggest that you commit it. Without this patch any combination of two TVH will suffer from this problem. The easiest environment is this: one TVH configured as SAT>IP server with only IPTV inputs; and a second one configured as SAT>IP server as well with the other serving as the SAT>IP input tuner. Without this patch, the second server never sends the error to the client.

So, please consider to commit the patch now until you find a better solution.
We hope you agree!
Regards,

#4 Updated by Jaroslav Kysela 24 days ago

  • Status changed from Accepted to Fixed

#5 Updated by Jaroslav Kysela 24 days ago

  • Status changed from Fixed to Accepted

Added another patch which should correctly identify the 'no data/bad service' state plus another bunch of cleanups and functional changes which I believe should fix the reported problems. v4.3-307-g4ee77e1

#6 Updated by Mono Polimorph 17 days ago

Jaroslav Kysela wrote:

Added another patch which should correctly identify the 'no data/bad service' state plus another bunch of cleanups and functional changes which I believe should fix the reported problems. v4.3-307-g4ee77e1

Hi,

After this patch, using two TVH servers ("remote" and "local"), and using the Windows free "SatIP DVBViewer" tool connected to the "local" server the scanning process is very slow... when using some IPTV inputs and some frequencies are empty.

See this log as example:

2017-08-03 17:44:17.359 mpegts: 10774H in ASTRA-192 - tuning on SAT>IP DVB-S Tuner #1 (10.100.120.2)(TCP)
2017-08-03 17:44:17.359 epggrab: 10774H in ASTRA-192 - registering mux for OTA EPG
2017-08-03 17:44:17.360 subscription: 000D: "SAT>IP" subscribing to mux "10774H", weight: 100, adapter: "SAT>IP DVB-S Tuner #1 (10.100.120.2)(TCP)", network: "ASTRA-192", service: "Raw PID Subscription", hostname="192.168.1.2" 
2017-08-03 17:44:17.449 satip: SAT>IP DVB-S Tuner #1 (10.100.120.2)(TCP) - RTSP SETUP error -5 (Input/output error) [6-405]
2017-08-03 17:44:19.360 subscription: 000D: service instance is bad, reason: Tuning failed
2017-08-03 17:44:19.363 mpegts: 10774H in ASTRA-192 - tuning on SAT>IP DVB-S Tuner #2 (10.100.120.2)(TCP)
2017-08-03 17:44:19.364 subscription: 000D: "SAT>IP" subscribing to mux "10774H", weight: 100, adapter: "SAT>IP DVB-S Tuner #2 (10.100.120.2)(TCP)", network: "ASTRA-192", service: "Raw PID Subscription", hostname="192.168.1.2" 
2017-08-03 17:44:19.450 satip: SAT>IP DVB-S Tuner #2 (10.100.120.2)(TCP) - RTSP SETUP error -5 (Input/output error) [6-405]
2017-08-03 17:44:21.361 subscription: 000D: service instance is bad, reason: Tuning failed
2017-08-03 17:44:23.364 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:25.362 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:27.363 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:29.364 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:31.362 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:33.362 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:35.363 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:37.364 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:39.365 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:41.366 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:43.367 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:45.368 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:47.368 subscription: 000D: No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192" 
2017-08-03 17:44:47.382 satips: 0/22F231CF/2: create mux DVB-S freq 10788000 V sym 22000000 fec 5/6 mod QPSK roff 35 is_id -1 pls_mode ROOT pls_code 0
2017-08-03 17:44:47.383 subscription: 000D: "SAT>IP" unsubscribing, hostname="192.168.1.2" 
2017-08-03 17:44:47.383 mpegts: 10774H in ASTRA-192 (0x7f66e773d360) - deleting
2017-08-03 17:44:47.383 mpegts: 10788V in ASTRA-192 - tuning on SAT>IP DVB-S Tuner #1 (10.100.120.2)(TCP)
2017-08-03 17:44:47.383 epggrab: 10788V in ASTRA-192 - registering mux for OTA EPG
2017-08-03 17:44:47.384 subscription: 000F: "SAT>IP" subscribing to mux "10788V", weight: 100, adapter: "SAT>IP DVB-S Tuner #1 (10.100.120.2)(TCP)", network: "ASTRA-192", service: "Raw PID Subscription", hostname="192.168.1.2" 
...

- As you can see, the client receives the error at some point (Time=0s)
"RTSP SETUP error -5 (Input/output error) [6-405]"

- At Time=2s, the subscription fails
"subscription: 000D: service instance is bad, reason: Tuning failed"
and the server tries the second tuner and it receives the same error (as the frequency is invalid in both tuners)

- At Time=4s, the subscription fails again,
and 2 seconds after a log message appears each two seconds
"No input source available for subscription "SAT>IP" to mux "10774H in ASTRA-192""

- And only at Time=26s, 20 seconds after the subscription is cancelled the client receives the error.

So, with around 50 frequencies invalid, around 50x30s are added, 25 minutes in total!
Can this time be improved?
Can the subscription be cancelled directly when the service instace is bad because a failed tuning?
I feel with a 405 Error is not need to wait more time!

#7 Updated by Mono Polimorph 17 days ago

Hi,

More info: When you have configured two tuners, and the you are using the first... and the RTSP connection is interrupted (I'm using tcpkill) you see this message:

2017-08-03 19:11:54.752 satip: SAT>IP DVB-S Tuner #1 (10.100.120.2) - RTSP error -104 (Connection reset by peer) [9874-0]
2017-08-03 19:11:55.421 subscription: 000C: service instance is bad, reason: Tuning failed
2017-08-03 19:11:55.422 mpegts: 11778V in ASTRA-192 - tuning on SAT>IP DVB-S Tuner #2 (10.100.120.2)

So the second Tuner is inmediatly started opening a new TCP RTSP connection.

However, when the same error appears and you are using the second tuner, then and error is triggered:

2017-08-03 19:12:22.375 satip: SAT>IP DVB-S Tuner #2 (10.100.120.2) - RTSP error -104 (Connection reset by peer) [9874-0]
2017-08-03 19:12:23.432 subscription: 000C: service instance is bad, reason: Tuning failed
2017-08-03 19:12:25.432 subscription: 000C: No input source available for subscription "SAT>IP" to mux "11778V in ASTRA-192" 
2017-08-03 19:12:27.433 subscription: 000C: No input source available for subscription "SAT>IP" to mux "11778V in ASTRA-192" 
2017-08-03 19:12:29.433 subscription: 000C: No input source available for subscription "SAT>IP" to mux "11778V in ASTRA-192" 
...

So, I suggest this:

  1. When a socket error closes the RTSP connection, try one time to reconnect to the same tuner.
  2. If the tuner fails, then request the next free in the list, even if the tuner number is lower.

You agree?

Also available in: Atom PDF