Project

General

Profile

Bug #2544

Astra 19.2E - 10832.25H, 12574.25H wrong mux parameters are broadcasted (auto discovery)

Added by Kai Sommerfeld over 5 years ago. Updated over 5 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
DVB
Target version:
-
Start date:
2014-12-10
Due date:
% Done:

100%

Estimated time:
Found in version:
3.9.2218
Affected Versions:

Description

Cannot tune to HD+ channels - always ending up with Kodi telling me after a minute or so "no input detected". Not sure whether all HD+ channels are affected, but "RTL HD" and some others definitely are. Experiencing this problem for many months now and it is still present in latest tvh revisions. And no, I don't have a general problem with descrambling.Interestingly, I found a workaround. If I apply the attached patch (which I use for months now for every of my tvh builds) everything works fine. I'm sure this patch fixes not the root cause of the problem, but... at least it gives me working HD+ channels.

Also please find attached to logs (both with debug and trace for mpegts,+linuxdvb,+descrambler. tvh-okay.log is for a successful RTL HD tune using 2218 with my patch, tvh-not-okay.log is for original 2218 build where tuning to RTL HD fails.


Files

tvh-okay.log (69.5 KB) tvh-okay.log tuning RTL HD succeeds (patched tvh) Kai Sommerfeld, 2014-12-10 12:21
tvh-not-okay.log (325 KB) tvh-not-okay.log tuning RTL HD fails (unpatched tvh) Kai Sommerfeld, 2014-12-10 12:21
tvheadend-999.995-01-fix-for-mpegts-network-discovery-fix.patch (581 Bytes) tvheadend-999.995-01-fix-for-mpegts-network-discovery-fix.patch patch Kai Sommerfeld, 2014-12-10 12:21

Associated revisions

Revision d6b59b9e (diff)
Added by Jaroslav Kysela over 5 years ago

mpegts network: create new muxes when delivery system does not match, fixes #2544

History

#1

Updated by B C over 5 years ago

Interesting as HD+ is working fine for me without any patch. Is this on CAID 1830 or 1843?

#2

Updated by Kai Sommerfeld over 5 years ago

I have a HD02 card (1843).

#3

Updated by Kai Sommerfeld over 5 years ago

Did some more checking. The problem is actually unraleted to HD+ channels. I discovered that the affected channels are all on muxes with scan status FAIL. No wonder that tuning for thise fails. But the big question is why my patch "heals" this problem. As a matter if fact, with my patch applied the muxes in question (Astra 19.2E: 10832.25H, 12574.25H) will be scanned OK and tuning works just fine.

Jaroslav, any chance that you take a look into this very strange problem. Will be happy to assist with logs, testing etc.

#4

Updated by Jaroslav Kysela over 5 years ago

OK: tuner DVBSky S952: Tuner 2 tunning to DVBS2 pos 19.2E freq 10832250 H sym 22000000 fec 2/3 mod PSK/8 roff 35 (freq 1082250)
FAIL: tuner DVBSky S952: Tuner 1 tunning to DVBS pos 19.2E freq 10832250 H sym 22000000 fec 5/6 mod QPSK roff 35 (freq 1082250)

It seems that there are multiple parameters for 10832.25H mux broadcasted on 19.2E and tvh choose the wrong config.. It appears that we need a blacklist or so...

#5

Updated by Jaroslav Kysela over 5 years ago

  • Subject changed from Cannot tune HD+ channels to Astra 19.2E - 10832.25H, 12574.25H wrong mux paramterers are broadcasted (auto discovery)
#6

Updated by Jaroslav Kysela over 5 years ago

  • Subject changed from Astra 19.2E - 10832.25H, 12574.25H wrong mux paramterers are broadcasted (auto discovery) to Astra 19.2E - 10832.25H, 12574.25H wrong mux parameters are broadcasted (auto discovery)
#7

Updated by Kai Sommerfeld over 5 years ago

Do you have an idea why my patch seems to fix things?

#8

Updated by Kai Sommerfeld over 5 years ago

Found this peace of code in mpegts_network_dvb.c:

/* the nit tables may be inconsistent (like rolloff ping-pong) /
/
accept information only from one origin mux */
if (mm->mm_dmc_origin_expire > dispatch_clock && mm->mm_dmc_origin && mm->mm_dmc_origin != mmo)
goto noop;

My patch is changing conditions for setting mm_dmc_origin_expire and mm_dmc_origin ... Maybe this could be related?

BTW: My patch basically reverts this commit: https://github.com/tvheadend/tvheadend/commit/34dd2b8da8d61fc21e6e4497a34259601b9e365f done Aug 12 2014

#9

Updated by B C over 5 years ago

I just checked those two TP on my side and both do and did scan well without the patch, so it seems the stream from your card is different from mine (TBS-6984). What kernel version do you run?

#10

Updated by Kai Sommerfeld over 5 years ago

I'm (almost always) running latest OpenELEC. The problem exists since August 2014 - lasts with different kernel versions.

#11

Updated by B C over 5 years ago

as jaroslav added, you seem to scan these frequencies with two different settings (so FEC and modulation are different), can you set them manually and check if they scan ok? Do you have both entries in your mux list? If so try to disable the wrong one.

#12

Updated by Jaroslav Kysela over 5 years ago

Kai Sommerfeld wrote:

Found this peace of code in mpegts_network_dvb.c:

/* the nit tables may be inconsistent (like rolloff ping-pong) /
/
accept information only from one origin mux */
if (mm->mm_dmc_origin_expire > dispatch_clock && mm->mm_dmc_origin && mm->mm_dmc_origin != mmo)
goto noop;

My patch is changing conditions for setting mm_dmc_origin_expire and mm_dmc_origin ... Maybe this could be related?

Yes, you changed the behaviour from "set these values on change" to "set these values always". It means that if you're lucky and your first hit is for the good mux parameters, you won. But it's not ideal solution. The ideal solution would be that broadcasters fix their tables.

Could you try this patch?

iff --git a/src/input/mpegts/mpegts_network_dvb.c b/src/input/mpegts/mpegts_network_dvb.c
index 1b37c81..aeb365c 100644
--- a/src/input/mpegts/mpegts_network_dvb.c
+++ b/src/input/mpegts/mpegts_network_dvb.c
@@ -285,6 +285,9 @@ dvb_network_find_mux
     /* Same FE type - this REALLY should match! */
     if (lm->lm_tuning.dmc_fe_type != dmc->dmc_fe_type) continue;

+    /* Also, the system type should match (DVB-S/DVB-S2) */
+    if (lm->lm_tuning.dmc_fe_delsys != dmc->dmc_fe_delsys) continue;
+
     /* if ONID/TSID are a perfect match (and this is DVB-S, allow greater deltaf) */
     if (lm->lm_tuning.dmc_fe_type == DVB_TYPE_S) {
       deltar = 10000;
@@ -444,7 +447,6 @@ dvb_network_create_mux
       lm->lm_tuning.dmc_fe_freq = dmc->dmc_fe_freq;
       save = 1;
     }
-    save |= COMPAREN(dmc_fe_delsys);
     save |= COMPAREN(dmc_fe_modulation);
     save |= COMPAREN(dmc_fe_inversion);
     save |= COMPAREN(dmc_fe_rolloff);

It should create two muxes for these frequencies one with the wrong parameters and second with correct parameters.

#13

Updated by Jaroslav Kysela over 5 years ago

B C wrote:

as jaroslav added, you seem to scan these frequencies with two different settings (so FEC and modulation are different), can you set them manually and check if they scan ok? Do you have both entries in your mux list? If so try to disable the wrong one.

No, these parameters are taken from MPEG-TS feeds from the satellite broadcast. The problem is that the wrong mux parameters are broadcasted and tvh selects sometimes these parameters and merges them to the mux on given frequency. My above patch will disallow merging for DVB-S and DVB-S2, but other parameters will be merged.

#14

Updated by B C over 5 years ago

hmmm, if the table would be inconsistent we should see that for different SW also, I never did run into this problem and I'm really scanning a lot :-), also I do tune 100% without the "patch" while Kai never tunes correctly without it, but it seems that he has a 100% hit rate with it. Is there some way to make a plain dump of the NIT when it arrives?

#15

Updated by Kai Sommerfeld over 5 years ago

It should create two muxes for these frequencies one with the wrong parameters and second with correct parameters.

Two muxes? How will tvh find and use the right one?

#16

Updated by B C over 5 years ago

they have a proper id, so primary key related to the service....

#17

Updated by Jaroslav Kysela over 5 years ago

Kai Sommerfeld wrote:

It should create two muxes for these frequencies one with the wrong parameters and second with correct parameters.

Two muxes? How will tvh find and use the right one?

One will be without services (no data).

#18

Updated by Jaroslav Kysela over 5 years ago

I did a full 19.2E scan and the culprit is here:

mpegts: 10862H in DVB-S 19.2E
...
nit: network 0001 (1) [Telewizja Polska SA]
nit:   onid 2268 (8808) tsid 0003 (3)
...
nit:     DVBS pos 19.2E freq 10832250 H sym 22000000 fec 5/6 mod QPSK roff 35

So Poland operator is bad...

All other muxes have correct parameters for this mux:

DVBS2 pos 19.2E freq 10832250 H sym 22000000 fec 2/3 mod PSK/8 roff 35
#19

Updated by Jaroslav Kysela over 5 years ago

B C wrote:

hmmm, if the table would be inconsistent we should see that for different SW also, I never did run into this problem and I'm really scanning a lot :-), also I do tune 100% without the "patch" while Kai never tunes correctly without it, but it seems that he has a 100% hit rate with it. Is there some way to make a plain dump of the NIT when it arrives?

It very depends on the order in which are muxes saved in the config directory in this case and it might be that Kai just has this order that this issue is 100% for him.

Use "--trace nit" to dump NIT tables...

#20

Updated by B C over 5 years ago

but that would mean the TP settings would only be wrong as long as 10862H was the last NIT tvh updated with

#21

Updated by B C over 5 years ago

or did I understand something wrong and we have had those two different transponder configs before but just didn't see them in the webfront end? So instead of updating it did write another conf?

#22

Updated by Kai Sommerfeld over 5 years ago

Confirming that the fix seems to work. Big THX.

Now having 22(!) duplicate muxes. Common to all is different delsys. But additionally are all combinations of different symbolrates, FEC, Rolloff, modulation ... all kind of mess.

Before your patch I already had 9 duplicate muxes. Those duplicates were created due to different symbolrate. Such a fix was already present in dvb_network_find_mux(). But gues what, all of these 9 also differ by delsys. Oh my gosh!

#23

Updated by Jaroslav Kysela over 5 years ago

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

Also available in: Atom PDF