Bug #5544
Failed to play hidden services
100%
Description
I have scanned a frequency that has certain channels that emit only sometimes, all of them work properly except two (M.LCAMPEON5 and M.LCAMPEON6). When I play them, it tells me that the service is not enabled (I have not touched any box) and if I map it to a channel, it tells me that the adapter is not available.
However with other players as an enigma the channel does work when it emits. Here never.
What I see in the tbl-base traces being different from the rest of services is this:
2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: type 01 (1) name [M.LCAMPEON6] provider [Movistar+] def_auth [] 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: type changed / old 01 (1) 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: name changed 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: provider changed
old? this is a service scan after deleting both services
P.S.: Attached full log
Files
History
Updated by 
Updated by Pablo R. almost 6 years ago
Attached full DVB-S network files for further analysis.
Updated by Jaroslav Kysela almost 6 years ago
Updated by Did you grab the logs when the service is broadcasted? There should be PMT scan:
PAT: 2019-02-14 20:02:31.837 [ DEBUG]:tbl-base: pat: sid 757C (30076) on pid 041A (1050) 2019-02-14 20:02:31.837 [ DEBUG]:mpegts: 11097V in Satelite - add service 757C (null) 2019-02-14 20:02:31.837 [ TRACE]:mpegts: table: mux 0x56463be54640 add pmt 02/FF (2) pid 041A (1050) SDT: 2019-02-14 20:02:34.693 [ DEBUG]:tbl-base: sdt: sid 757C (30076) running 4 free_ca 1 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: dtag 48 dlen 23 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: dtag 8C dlen 16 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: dtag 88 dlen 25 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: dtag 86 dlen 6 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: type 01 (1) name [M.LCAMPEON6] provider [Movistar+] def_auth [] 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: type changed / old 01 (1) 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: name changed 2019-02-14 20:02:34.693 [ TRACE]:tbl-base: sdt: provider changed 2019-02-14 20:02:34.694 [ DEBUG]:tbl-base: sdt: nicename Satelite/11097V/M.LCAMPEON6 PMT: <pre> .... [ DEBUG]:tbl-base: pmt: sid 757C (30076) </pre> nowhere...
Updated by Jaroslav Kysela almost 6 years ago
I see it. It looks like PID subscription problem. The PMT PIDs >= 1049 are not subscribed from the tuner.
Updated by Pablo R. almost 6 years ago
Jaroslav Kysela wrote:
I see it. It looks like PID subscription problem. The PMT PIDs >= 1049 are not subscribed from the tuner.
So is it a SAT>IP tuner problem?
Updated by Pablo R. almost 6 years ago
2019-02-14 20:02:32.616 [ TRACE]:satip: 0005: PLAY params - addpids=1024,1025,1026,1027,1028,1029,1030,1031,1032,1033,1034,1035,1036,1037,1038,1039,1040,1041,1042,1043,1044,1045,1046,1047,1048 2019-02-14 20:02:32.751 [ TRACE]:satip: Status string: 'ver=1.0;src=1;tuner=1,176,1,15,11097.00,v,dvbs,qpsk,off,0.35,22000,56;pids=0,1,16,17,1024,1025,1026,1027,1028,1029,1030,1031,1032,1033,1034,1035,1036,1037,1038,1039,1040,1041,1042,1043,1044,1045,1046,1047,1048'
Am I wrong or TVH is not requesting these PIDs?
Updated by Jaroslav Kysela almost 6 years ago
TVH limits the concurrent PIDs to the configured value (see the client config - it's usually 32), but it should unsubscribe and subscribe the another group during the scan. Unfortunately, something prevents to do this in your setup. I just did a quick test for 19.2E 12363V and it works good here (the PMT PIDs are splitted):
2019-02-15 21:51:28.240 [ TRACE]:satip: 0003: SETUP params - src=5&fe=3&freq=12363&sr=27500&msys=dvbs&mtype=qpsk&pol=v&fec=34&ro=0.35&pids=0 2019-02-15 21:51:28.308 [ TRACE]:satip: 0003: PLAY params - addpids=1,16,17 2019-02-15 21:51:30.043 [ TRACE]:satip: 0003: PLAY params - addpids=1273,1274,1276,1277,1278,1279,1281,1282,1283,1284,1285,1286,1287,1288,1289,1290,1291,1293,1294,1296,1301,1302,1303,1304,1305 2019-02-15 21:51:32.009 [ TRACE]:satip: 0003: PLAY params - delpids=1273,1274,1276,1277,1278,1279,1281,1282,1283,1284,1285,1286,1287,1288,1289,1290,1291,1293,1294,1296,1301,1302,1303,1304,1305 2019-02-15 21:51:32.010 [ TRACE]:satip: 0003: PLAY params (split) - addpids=1312,1313,1314,1315,1325,1326,1327,1328,1329,1330,1331,1341,1342,1345,4050 2019-02-15 21:51:33.981 [ TRACE]:satip: 0003: PLAY params - delpids=1312,1313,1314,1326,1327,1328,1330,1331,1341,1342,1345,4050 2019-02-15 21:51:35.032 [ TRACE]:satip: 0003: PLAY params - delpids=1325,1329
Updated by Pablo R. almost 6 years ago
Jaroslav Kysela wrote:
TVH limits the concurrent PIDs to the configured value (see the client config - it's usually 32), but it should unsubscribe and subscribe the another group during the scan. Unfortunately, something prevents to do this in your setup. I just did a quick test for 19.2E 12363V and it works good here (the PMT PIDs are splitted):
[...]
I have PID limit set at 64. Maybe these PID limit is partially applied?
I mean, in normal retransmissions 64 PIDs can be used, but in the case of scans this is hard limited to 32 (25) - no splits and no more pids ?
Updated by Jaroslav Kysela almost 6 years ago
- File test1.patch test1.patch added
Add this patch and do another scan for the problematic mux:
diff --git a/src/input/mpegts/satip/satip_frontend.c b/src/input/mpegts/satip/satip_frontend.c
index dd2ff67f9..8b161baa6 100644
--- a/src/input/mpegts/satip/satip_frontend.c
+++ b/src/input/mpegts/satip/satip_frontend.c
@@ -915,6 +915,11 @@ satip_frontend_update_pids
if (lfe->sf_device->sd_pids21)
mpegts_pid_add(&tr->sf_pids, 21, MPS_WEIGHT_PMT_SCAN);
}
+ {
+ char buf[2048];
+ mpegts_pid_dump(&tr->sf_pids, buf, sizeof(buf), 1, 1);
+ tvhtrace(LS_SATIP, "update pids: %s", buf);
+ }
tvh_mutex_unlock(&lfe->sf_dvr_lock);
tvh_write(lfe->sf_dvr_pipe.wr, "c", 1);
Updated by Jaroslav Kysela almost 6 years ago
Nevermind. I see it in the code, you extended the PID limit, but it cannot be stored to the 127 characters per request and the current implementation in satip_rtsp_play() is a bit dumb, so the additional PIDs are just silently stripped. Try to extend also the maximum length of PIDs (twice).
Updated by Pablo R. almost 6 years ago
Jaroslav Kysela wrote:
Nevermind. I see it in the code, you extended the PID limit, but it cannot be stored to the 127 characters per request and the current implementation in satip_rtsp_play() is a bit dumb, so the additional PIDs are just silently stripped. Try to extend also the maximum length of PIDs (twice).
You are right. When increasing PID lenght it works.
Is this a definitive solution? We should increase the PID lenght for the satip triax and kathrein in that case (device/firmware-specific workarounds).
Updated by Jaroslav Kysela almost 6 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset commit:tvheadend|cc70226210f9888d58a205cf903d89c9b499ab97.
Updated by Jaroslav Kysela almost 6 years ago
I hope that this is fixed for all configs now. The split method was improved and it is more universal now.
Updated by Pablo R. almost 6 years ago
There is something wrong
2019-02-16 11:06:00.111 [ TRACE]:satip: SAT>IP DVB-S Tuner - local RTP port 47548 RTCP port 47549 2019-02-16 11:06:00.111 [ TRACE]:satip: 0025: SETUP params - src=1&fe=3&freq=11317.5&sr=22000&msys=dvbs&mtype=qpsk&pol=v&fec=56&ro=0.35&pids=0 2019-02-16 11:06:00.288 [ DEBUG]:satip: 192.168.1.138 #2 - new session 274583595269ab82 stream id 2392 2019-02-16 11:06:00.288 [ TRACE]:satip: 0024: PLAY params[0] - addpids=1,16,17,47,100,101,165,1029p���Z^? 2019-02-16 11:06:00.423 [ DEBUG]:satip: 192.168.1.138 #3 - new session 2745840676923d79 stream id 2393 2019-02-16 11:06:00.423 [ TRACE]:satip: 0025: PLAY params[0] - addpids=1,16,17,38,88,89,162,1036p���Z^? 2019-02-16 11:06:00.425 [ ERROR]:satip: SAT>IP DVB-S Tuner #2 (192.168.1.138@UDP) - RTSP cmd error 7 (DONE) [8-400] 2019-02-16 11:06:00.431 [ ERROR]:satip: SAT>IP DVB-S Tuner #3 (192.168.1.138@UDP) - RTSP cmd error 7 (DONE) [8-400]