Tvheadend

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?

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.

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

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.

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

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

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.

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.

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...

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.

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.

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.

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)

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.

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?

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.

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.

[...]

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.

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

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 ?

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

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.

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.

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..

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?

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.

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 ?

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!