Project

General

Profile

Bug #2474

Wrong linuxdvb tune (silent): Duplicated/Mixed services in DVB-T multiplexes

Added by Rafal Kupiec about 10 years ago. Updated almost 10 years ago.

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

0%

Estimated time:
Found in version:
3.9.2.2075
Affected Versions:

Description

I am receiving 3 multiplexes in DVB-T. Each of them contain 8 channels.
However after some time (few TVH restarts?) tvheadend is reporting more services. Number of services is increasing, until every mux reports all channels from all multiplexes.

What is more, the 'duplicated services' that belong to incorrect MUX, does not contain any valid information, except SID.
I have tried setting 'skip initial bytes' to 64000 as well as 128000, but without success. The only difference after increasing this is that tvh reports scan status as failed after restart.

I am attaching screenshot to show, how it looks like in TVH. As can be seen, channel named "TVP Info" is served from 698MHz, but somehow there is a service w/o name and with the same SID (35) available on another MUX - 586MHz.


Files

dvbt1.png (11.2 KB) dvbt1.png Rafal Kupiec, 2014-11-13 00:16
dvbt2.png (7.23 KB) dvbt2.png Rafal Kupiec, 2014-11-13 00:17
fakeservices.png (103 KB) fakeservices.png Brendan Pike, 2014-11-16 02:03
tvh_debug.log (1.05 MB) tvh_debug.log logfile Brendan Pike, 2014-11-18 21:55
tvh_debug_vct.log (279 KB) tvh_debug_vct.log Brendan Pike, 2014-11-19 04:21
xxtvh_debug.log.tar.bz2 (1.68 MB) xxtvh_debug.log.tar.bz2 Hans-Gerhard Schehl, 2014-11-19 23:51
14-11-19--23-29-TVH-2.JPG (93.8 KB) 14-11-19--23-29-TVH-2.JPG Hans-Gerhard Schehl, 2014-11-20 00:03
14-11-19--23-28-TVH-1.JPG (181 KB) 14-11-19--23-28-TVH-1.JPG Hans-Gerhard Schehl, 2014-11-20 00:03
14-11-19--23-44-TVH-3.JPG (125 KB) 14-11-19--23-44-TVH-3.JPG Hans-Gerhard Schehl, 2014-11-20 00:03
adding-634mhz-dvbt_tsid-ok.log (23.3 KB) adding-634mhz-dvbt_tsid-ok.log Thomas Reitmayr, 2014-12-14 13:42
adding-634mhz-dvbt_tsid-wrong.log (17.9 KB) adding-634mhz-dvbt_tsid-wrong.log Thomas Reitmayr, 2014-12-14 13:42
adding-634mhz-dvbt_tsid-ok-2.log (19.3 KB) adding-634mhz-dvbt_tsid-ok-2.log Thomas Reitmayr, 2014-12-14 22:29
adding-634mhz-dvbt_tsid-wrong-2.log (22.3 KB) adding-634mhz-dvbt_tsid-wrong-2.log Thomas Reitmayr, 2014-12-14 22:29
nit+pat.log (3.63 KB) nit+pat.log (from dvbsnoop) Thomas Reitmayr, 2014-12-14 22:29

History

#1

Updated by Rafal Kupiec about 10 years ago

I think I have fixed this by enabling 'skip initial scan' in networks containing dvb-t muxes.
Anyway, I wonder if it doesn't skip (break) anything else, do it?

#2

Updated by Jaroslav Kysela about 10 years ago

Provide the '--trace sdt,nit,bat,mpegts' when you can hit the bug (remove wrong services and then restart tvh and wait until wrong services are created again). The initial scan should work - it would be good to identify the cause of this behaviour.

#3

Updated by Rafal Kupiec about 10 years ago

I have reenabled initial scan, added mentioned parameters and after restart they appeared again.
I will provide logs directly to perexg.

#4

Updated by Brendan Pike about 10 years ago

I am seeing the exact same thing with ATSC. Dual tuner hdhomerun devices getting bad duplicate services on certain channels.

See attached pic, The real muxes that work are marked in green, the bad ones are marked in red that are just dead air.
I had to manually add the real WNED-HD and its subchannel Think (RF43) and CHCH-DT (RF15) as it would only automatically scan in the bad ones as services and ignore the real ones completely.
Also note the other duplicates like CBLT-DT and CFMT.

This bug has been around a long time but I've always easily worked around it. I have no idea where to look as to the cause.

#5

Updated by Brendan Pike about 10 years ago

Forgot to add, I can delete all the services marked in red, and they will simply keep coming back on idle scan or initial scan, despite there being nothing on those bands.

#6

Updated by Rafal Kupiec about 10 years ago

Correct. The same behaviour. Good to know there are more users affected.

#7

Updated by Hans-Gerhard Schehl about 10 years ago

Hi all,

see also https://tvheadend.org/boards/5/topics/13857
I thought it was a Unicable-related problem, but it seems to be a general one ...

HG

#8

Updated by Jaroslav Kysela about 10 years ago

No idea. The recent fixes in 3.9.2081 might fix that. Give a test.

I also tried to create a immediate buffer flush patch here https://github.com/perexg/tvheadend/tree/linuxdvb-flush , https://github.com/perexg/tvheadend/commit/10c6562dd952ef0211f54032d31ab5a3e595c070 , but I don't think that it will change something. But test it.. It's only for linuxdvb, for hdhomerun - no idea.

#9

Updated by Jaroslav Kysela about 10 years ago

BTW: I still think that the start of received stream is wrong (some MPEG-TS packets from previous mux tuning?) so tvh wrongly assigns new services to a wrong mux.

#10

Updated by Hans-Gerhard Schehl about 10 years ago

That sounds reasonable for me, because it could also explain the other error with adapter0 I have (see my prev. posts in the board).

I try to provide a log as requested in #2 ASAP. I will also add "--logfile tvh_debug.log --debug diseqc,en50494,linuxdvb" ...

To test the patch I'm afraid I'm not experienced enough in Linux. At least I installed 3.9.2083...

#11

Updated by Brendan Pike about 10 years ago

Log attached, watch for the usual ones to rescan that aren't there. CFMT, CBLT-DT, WNED, Think, CHCH, etc.

#12

Updated by Jaroslav Kysela about 10 years ago

Brendan Pike wrote:

Log attached, watch for the usual ones to rescan that aren't there. CFMT, CBLT-DT, WNED, Think, CHCH, etc.

Could you do same, but with '--trace sdt,nit,bat,vct,mpegts' ? Note that 'vct' table is for ATSC. I don't see it in the provided log.

#13

Updated by Brendan Pike about 10 years ago

Attached with vct data.

Thanks,

#14

Updated by Hans-Gerhard Schehl about 10 years ago

So here's my log for it:
  • starting at ~23:03 where I had shortly before deleted all the "failed" muxes (see 14-11-19--23-29-TVH-2.jpg)
  • at ~23:22 all the duplicate muxes (the marked lines in 14-11-19--23-29-TVH-2.jpg) had reappeared (see also 14-11-19--23-28-TVH-1.JPG).
  • at ~23:31 I switched the working adapter1 (CineS2@1400) off and the non-working (CineS2@1516) on. After a manually started scan of all the muxes with a Transport Stream ID of <100 eight additional muxes failed their scan (IDs 6 & 8-14, see also 14-11-19--23-44-TVH-3.JPG)
  • from former experience: if I had continued scanning with adapter0 most of the muxes would have been gone ...

I hope I could help in debugging this issue (still being prepared to provide additional logs etc.)

BTW: Cine S2 6.5, Xubuntu 14.04 LTS fully updated, TVH 3.9.2114

#15

Updated by Jaroslav Kysela about 10 years ago

Brendan Pike wrote:

Attached with vct data.

Thanks,

The services without names were loaded from the configuration (storage). I don't see any new empty services added from scan in this log.

#16

Updated by Jaroslav Kysela about 10 years ago

Hans-Gerhard Schehl wrote:

So here's my log for it:
  • starting at ~23:03 where I had shortly before deleted all the "failed" muxes (see 14-11-19--23-29-TVH-2.jpg)

Analyzed only one mux 11817V:

Wrong info from provider:

network: "ASTRA", mux: "10861.75H" 
nit:     DVBS pos 19.2E freq 11817000 V sym 27500000 fec 3/4 mod QPSK roff 35

Correct info from provider:

network: "ASTRA", mux: "10876.5V" 
nit:     DVBS2 pos 19.2E freq 11817000 V sym 29700000 fec 5/6 mod QPSK roff 25

So about the wrong muxes - the information is in the MPEG-TS stream. The providers just have inconsistency in their tables. There is no way than:

1) disable autodiscovery and use only really known muxes
2) or disable only wrong muxes manually when they're discovered

In this case TVH does not know which transponder parameters are valid, because TVH trust to everything which is received in the autodiscovery mode.

#17

Updated by Brendan Pike about 10 years ago

Jaroslav Kysela wrote:

Brendan Pike wrote:

Attached with vct data.

Thanks,

The services without names were loaded from the configuration (storage). I don't see any new empty services added from scan in this log.

You've missed them. Its happening here:
2014-11-18 22:11:37.242 [ DEBUG]:mpegts: 479.28MHz in ATSC - add service 0003 (null)
2014-11-18 22:11:37.243 [ DEBUG]:mpegts: 647.28MHz in ATSC - add service 000A (null)
2014-11-18 22:11:37.243 [ DEBUG]:mpegts: 647.28MHz in ATSC - add service 0003 (null)
2014-11-18 22:11:37.243 [ DEBUG]:mpegts: 647.28MHz in ATSC - add service 0004 (null)
2014-11-18 22:16:47.527 [ DEBUG]:mpegts: 677.28MHz in ATSC - add service 0002 (null)
2014-11-18 22:17:12.489 [ DEBUG]:mpegts: 659.28MHz in ATSC - add service 0003 (null)
2014-11-18 22:18:28.033 [ DEBUG]:mpegts: 497.28MHz in ATSC - add service 0003 (null)
2014-11-18 22:18:28.033 [ DEBUG]:mpegts: 497.28MHz in ATSC - add service 0004 (null)
2014-11-18 22:19:18.046 [ DEBUG]:mpegts: 611.28MHz in ATSC - add service 0003 (null)

#18

Updated by Brendan Pike about 10 years ago

The services it is adding aren't even on the correct frequencies either. There is an obvious race condition going on where TVH is adding services on frequencies it thinks it is tuned to, but was not.

#19

Updated by Rafal Kupiec about 10 years ago

Jaroslav Kysela wrote:

1) disable autodiscovery and use only really known muxes
2) or disable only wrong muxes manually when they're discovered

OK. I have manually added 3 DVB-T muxes.
Situation looks identical, just I'm facing fake services in those muxes.
What could you propose here?

#20

Updated by Jaroslav Kysela about 10 years ago

Brendan Pike wrote:

Jaroslav Kysela wrote:

Brendan Pike wrote:

Attached with vct data.

Thanks,

The services without names were loaded from the configuration (storage). I don't see any new empty services added from scan in this log.

You've missed them. Its happening here:
2014-11-18 22:11:37.242 [ DEBUG]:mpegts: 479.28MHz in ATSC - add service 0003 (null)
2014-11-18 22:11:37.243 [ DEBUG]:mpegts: 647.28MHz in ATSC - add service 000A (null)
2014-11-18 22:11:37.243 [ DEBUG]:mpegts: 647.28MHz in ATSC - add service 0003 (null)
2014-11-18 22:11:37.243 [ DEBUG]:mpegts: 647.28MHz in ATSC - add service 0004 (null)
2014-11-18 22:16:47.527 [ DEBUG]:mpegts: 677.28MHz in ATSC - add service 0002 (null)
2014-11-18 22:17:12.489 [ DEBUG]:mpegts: 659.28MHz in ATSC - add service 0003 (null)
2014-11-18 22:18:28.033 [ DEBUG]:mpegts: 497.28MHz in ATSC - add service 0003 (null)
2014-11-18 22:18:28.033 [ DEBUG]:mpegts: 497.28MHz in ATSC - add service 0004 (null)
2014-11-18 22:19:18.046 [ DEBUG]:mpegts: 611.28MHz in ATSC - add service 0003 (null)

No, in time ~37.242 the services are loaded from config (wrong).

The services added later are all:

2014-11-18 22:19:18.046 [ DEBUG]:vct: chname CBLT-DT
2014-11-18 22:19:18.046 [ DEBUG]:mpegts: 611.28MHz in ATSC - add service 0003 (null)

Code:

   /* Find the service */
    if (!(s = mpegts_service_find(mm, sid, 0, 1, &save)))
      goto next;

    /* Update */
    if (strcmp(s->s_dvb_svcname ?: "", chname)) {
      tvh_str_set(&s->s_dvb_svcname, chname);
      save = 1;

So the message is from mpegts_service_find() and s_dvb_svcname is set after... These all look correct.
You should check the mux/tsid/sid values and show me the wrongly added services.

#21

Updated by Jaroslav Kysela about 10 years ago

Rafal Kupiec wrote:

Jaroslav Kysela wrote:

1) disable autodiscovery and use only really known muxes
2) or disable only wrong muxes manually when they're discovered

OK. I have manually added 3 DVB-T muxes.
Situation looks identical, just I'm facing fake services in those muxes.
What could you propose here?

It was for DVB-S not for your case.

#22

Updated by Brendan Pike about 10 years ago

[...]

So the message is from mpegts_service_find() and s_dvb_svcname is set after... These all look correct.
You should check the mux/tsid/sid values and show me the wrongly added services.

CBLT-DT is not on 611.28MHz at all, but 509.28, as indicated in my png image attached. Why is it adding another CBLT-DT on 611.28MHz? Its simply dead air.

#23

Updated by Brendan Pike about 10 years ago

Furthermore if you look around that log entry, it is doing a scan on 509.28MHz.

#24

Updated by Jaroslav Kysela about 10 years ago

Brendan Pike wrote:

Furthermore if you look around that log entry, it is doing a scan on 509.28MHz.

Right, but the service is assigned to the MUX identified using TSID. If you look to log, from config two muxes with this TSID are loaded:

2014-11-18 22:11:37.244 [  DEBUG]:mpegts: ATSC - adding mux Multiplex [onid:FFFF tsid:43A1] in ATSC to scan queue weight 4 flags 0020
2014-11-18 22:11:37.244 [  TRACE]:mpegts: Multiplex [onid:FFFF tsid:43A1] in ATSC - created
2014-11-18 22:11:37.244 [  DEBUG]:mpegts: 509.28MHz in ATSC - add service 0003 CBLT-DT
2014-11-18 22:11:37.244 [  DEBUG]:mpegts: ATSC - adding mux Multiplex [onid:FFFF tsid:43A1] in ATSC to scan queue weight 4 flags 0020

2014-11-18 22:19:18.046 [  DEBUG]:vct: tsid 43A1 (17313)
2014-11-18 22:19:18.046 [  DEBUG]:vct: channel count 1
2014-11-18 22:19:18.046 [  DEBUG]:vct: tsid   43A1 (17313)
2014-11-18 22:19:18.046 [  DEBUG]:vct: sid    0003 (3)
2014-11-18 22:19:18.046 [  DEBUG]:vct: chname CBLT-DT
2014-11-18 22:19:18.046 [  DEBUG]:vct: chnum  5.1
2014-11-18 22:19:18.046 [  DEBUG]:vct: type   02 (2)
2014-11-18 22:19:18.046 [  DEBUG]:mpegts: 611.28MHz in ATSC - add service 0003 (null)

The wrong MUX is 611.28MHz . Could you remove it / add it again and keep logging until TSID changes to 43A1 for this MUX ?

#25

Updated by Jaroslav Kysela about 10 years ago

Note that GUI will show the value 17313 (decimal).

#26

Updated by Brendan Pike about 10 years ago

This makes a lot more sense now. Any idea why it would add so many duplicate TSID's on many muxes?
Apart from deleting and then readding, is there an easy way to set them all back to 65535 manually other than config editing?
It would eliminate me having to rescan for the channels and remapping them.

Manually removing the bad muxes and readding them fixed the problem, they now correctly map the service name.

#27

Updated by Brendan Pike about 10 years ago

Still confused why there were duplicates, but this could be just an old bug long since fixed and not readding the ATSC mux list to refresh everything.

#28

Updated by Jaroslav Kysela about 10 years ago

The mux config is in $CFG/input/dvb/networks/*/muxes/* - you need to find the right file (probably by the frequency) and edit the TSID value using a text editor..

#29

Updated by Rafal Kupiec almost 10 years ago

Last time, you have introduced the feature which automatically disables services which are not mentioned in PAT.
Due to this I had almost all DVB-T services disabled. Also, disabling initial scan doesn't prevent TVH from adding duplicated services during epg grab.

Thus I would like to ask, if it is possible to implement some feature, which could be enabled per MUX or per network.
When enabled, TVH would NOT interfere with services from this MUX / network. Thanks to that, services won't be automatically disabled and no new services would be added / updated.
This has 1 disadvantage - when anything changes in MUX, it would require action from administrator. Anyway such situations happens much much more rare than tvh break DVB-T playback for me.

Also looks like there are more people affected by this issue.
Could you consider implementing such feature, please?

#30

Updated by Thomas Reitmayr almost 10 years ago

I guess I have the same problem. In my attachments I added a DVB-T MUX at 634 MHz which in the first file receives the wrong TSID 100 (which is from another MUX), in the second log file the TSID is correctly detected as 185.

In other occurrences the TSID changed from the correct value to 100 leading to duplicate services from that MUX while OTA EPG ceased getting information for the original TSID.

This problems seems to be related or identical to ticket #2068.

#31

Updated by Jaroslav Kysela almost 10 years ago

Thomas Reitmayr wrote:

I guess I have the same problem. In my attachments I added a DVB-T MUX at 634 MHz which in the first file receives the wrong TSID 100 (which is from another MUX), in the second log file the TSID is correctly detected as 185.

In other occurrences the TSID changed from the correct value to 100 leading to duplicate services from that MUX while OTA EPG ceased getting information for the original TSID.

This problems seems to be related or identical to ticket #2068.

Could you create same logs, but add '--trace linuxdvb' ? It seems like a tune mismatch.

#32

Updated by Thomas Reitmayr almost 10 years ago

Here are the requested log files plus the decoded NIT+PAT from dvbsnoop (not sure if that helps).

#33

Updated by Jaroslav Kysela almost 10 years ago

Thomas Reitmayr wrote:

Here are the requested log files plus the decoded NIT+PAT from dvbsnoop (not sure if that helps).

Thanks. It seems that the tuning is failing and the previous mux settings is used ?

I tried to add 'Tune Repeats' to v3.9-2254-g82cb4f7 . Could you set this value to 10 or so and retest ?

#34

Updated by Thomas Reitmayr almost 10 years ago

Jaroslav Kysela wrote:

Thanks. It seems that the tuning is failing and the previous mux settings is used ?

I tried to add 'Tune Repeats' to v3.9-2254-g82cb4f7 . Could you set this value to 10 or so and retest ?

That helped indeed, but 10 did not work, so I used 3 instead with success.

You were right that tuning did not work (although the ioctl did not fail). The third MUX I was trying to add always adopted the TSID of the MUX the tuner was last tuned to. So when I watched a channel on MUX A and stop watching, and then create the MUX entry for MUX C, it will adopt the TSID of MUX A. Same with MUX B. The same happened when intermediately tuning to MUX A or B with an external program, eg. tzap.

To me that all sounds a bit like a "weakness" of the linux driver or the hardware. I will keep an eye on the TSID to see if also the spontaneous changes to a wrong TSID are gone now. And hopefully it fixes the problem also for the other bug reporters...

Thanks a lot so far!

#35

Updated by Jaroslav Kysela almost 10 years ago

  • Subject changed from Duplicated services in DVB-T multiplexes to Wrong linuxdvb tune (silent): Duplicated/Mixed services in DVB-T multiplexes
#36

Updated by Jaroslav Kysela almost 10 years ago

  • Status changed from New to Fixed

I'm closing this. Tvheadend cannot do much if data are coming from other mux than asked from the driver/firmware/hardware. The newly introduced "Tune Repeats" settings might cure something, but it would be better to push driver authors to fix this issue..

Also available in: Atom PDF