TVHEADEND - E2 type DVB-T & DVB-C bouquet entries fail to automap but DVB-S entries are mapped ok

JohnBoyz · 15 December 2018 11:52

I use a Tanix Tx3 mini with the latest CoreElec.

I have a bouquet file for DVB-T channels which are broadcast in this locale.
I can use that file successfully on tvheadend on my main PC, but both the tvh version and build type are different to the Tanix.
On my main PC (Intel i7) this version is installed and working

HTS Tvheadend 4.2.1
Build: 4.2.1 (2017-05-23T12:20:11-05:00)

On the Tanix I have this

HTS Tvheadend 4.2.6-62 ~ CoreELEC Tvh-addon v9.0.116
Build: 4.2.6-62 ~ CoreELEC Tvh-addon v9.0.116 (2018-11-16T03:41:23+0000)

The DVB-T channels are not seen in tvh when the bouquet is enabled on the Tanix … but my PC has no such problems.

I am seeking some feedback from other DVB-T users to try to determine if the problem stems from

tvh version
build type (ARM Vs x86_64)
OS in use
or
Something I have done differently on the Tanix

Is anyone else experiencing this problem?

This is the complete content of my bouquet file

#NAME   -- DVB-T TV --

#SERVICE 1:0:1:835:3EA:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:44E:3E9:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:44F:3E9:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:452:3E9:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:837:3EA:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:450:3E9:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:83B:3EA:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:83F:3EA:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:451:3E9:2174:EEEE0000:0:0:0:
#SERVICE 1:0:1:44D:3E9:2174:EEEE0000:0:0:0:

mfizz · 15 December 2018 19:08

This is an open issue on tvheadend issues list. I think it’s something to do with how tvh is compiled for coreelec. I have tried to do a trace debug for other issues as well to no success.

Might be worth trying a le build seeing if the issues persist

JohnBoyz · 15 December 2018 23:35

I went looking for the most recent image from LE but found nothing specifically for my Tanix S905w
Did I miss it? I looked here
https://libreelec.tv/2018/12/libreelec-leia-v8-90-009-alpha/

I used the Generic image from that page and tested it, and the DVB-T channels worked properly in tvh.
That appears to narrow things down a little … ARM or OS build of tvh?

Maybe LE could be checked on a R-Pi?

mfizz · 17 December 2018 18:34

I think it might be the coreelec build of these addons, one of the build leaders would need to comment

mfizz · 17 December 2018 23:05

@JohnBoyz can you move this thread into kodi addons section and add that both DVB-C/T seem to have this issue but DVB-S is okay.

That way we can get the right attention on this.

For reference here is the tvh issue: 5387

JohnBoyz · 18 December 2018 00:07

I believe an admin would need to move the thread … and I have no problems with that should it be desired.

mfizz · 20 December 2018 01:04

An update on this? It seems to be a coreelec exclusive issue. Could we get any dev who knows to look at this?

JohnBoyz · 20 December 2018 11:02

Is it possibly an ARM issue?
Have you been able to check if the problem exists on other arm OSs or devices not supported by CoreElec?

JohnBoyz · 20 December 2018 12:14

I dug out an old R-P 1 and installed LibreElec RPi.arm-8.90.005 on it.
I did only a quick check … the R-Pi 1 does not ‘run’ but slowly walks through things

Unless I made an error with the Bouquet path, the problem is there also.

I will update this if I have further news.

JohnBoyz · 20 December 2018 14:51

Updated to LE 8.90.009 which produced the same problem on R-Pi 1

It appears that either CE & LE are using the same build (or method of building) or the ARM version of tvh is problematic.

mfizz · 20 December 2018 14:58

I thought you took a generic s905 build and it worked. 3rd post

JohnBoyz · 20 December 2018 15:24

Yes I did (on an x86_64 PC as it would not run on an ARM device of course) … not sure what your point is?

I have only found the problem with ARM builds - both CE & LE.

.
EDIT:
For clarity I have done the following installs and tested the same two bouquet files on them all with results as reported

LE to R-Pi 1 (two LE versions)                    DVB-T does not work
LE to R-Pi 2                                      DVB-T does not work
CE to Tanix Tx3 mini                              DVB-T does not work
LE to X86_64 PC (latest Generic image)            **DVB-T does work**
The DVB-S bouquet file worked on all.

From this there seems to be just two areas in common

CE being forked from LE might well have the same problem with the ARM build due to shared code.
tvh has a problem with its ARM implementation.

Hopefully a dev can look at this.

JohnBoyz · 23 December 2018 22:28

Lots of views of this thread (250+), but only two of us participating unfortunately, and both of us have the same problem.
It would help if another could test with an E2 style bouquet for DVB-T channels.

Hopefully one of the devs who is familiar with the tvheadend build for CE will post and let us know their thoughts on this.

JohnBoyz · 31 December 2018 18:54

I am beginning to think no one is using CE to watch terrestrial tv.

I opened a thread on LE also, but have not had any better luck there.

Bug #5387 on tvheadend does not even have anyone assigned to it, so I guess it is not getting any attention there either.
This link was given for the relevant code

github.com

tvheadend/tvheadend/blob/release/4.2/src/input/mpegts/mpegts_service.c#L653


static int
mpegts_service_match_mux(dvb_mux_t *mm, uint32_t hash, const idclass_t *idc)
{
  extern const idclass_t dvb_mux_dvbs_class;
  dvb_mux_t *mmd;
  int freq, pol;

  if ((hash & 0xffff) == 0) return 1;
  if (idc != &dvb_mux_dvbs_class) return 0;
  freq = (hash & 0x7fff) * 1000;
  pol = (hash & 0x8000) ? DVB_POLARISATION_HORIZONTAL : DVB_POLARISATION_VERTICAL;
  mmd = mm;
  return mmd->lm_tuning.u.dmc_fe_qpsk.orbital_pos == pol &&
         deltaU32(mmd->lm_tuning.dmc_fe_freq, freq) < 2000;
}
#endif

service_t *
mpegts_service_find_e2(uint32_t stype, uint32_t sid, uint32_t tsid,
                       uint32_t onid, uint32_t hash)
{

Maybe whoever builds tvheadend for CE could have a look to see why DVB-S entries have no problem being automapped but DVB-T entries all fail to automap?

afl1 · 1 January 2019 10:56

We never patched tvheadend. You have to ask tvheadend team to fix this issue.

JohnBoyz · 1 January 2019 11:12

Thanks for that info.

There is a bug report open on tvheadend but I was unsure about how this all becomes available in CE.

So no patches applied, but what about the build? For instance, is there maybe some build option that is accidentally omitted when the package is built for ARM/CE?
It does seem strange that this functions as expected in X86_64 builds I have tried, but not in ARM builds. (I have tried LE X86_64 and ARM, and CE ARM)

Anything you can add would be appreciated, thanks.

afl1 · 1 January 2019 11:29

TVH updates are maintained by CvH from LE. We only merge them from LE.

JohnBoyz · 1 January 2019 11:51

Thank you.
That clarifies things a lot.

I will continue to raise the matter with CvH.

I think this thread can be closed as it is an upstream matter it seems.

Maybe a mention to upstream devs about the problem would not go astray?

anon88919003 · 3 January 2019 02:23

LibreELEC developers are not interested in any kind of collaboration unfortunately.

JohnBoyz · 15 January 2019 13:33

The problem was raised in this thread

and essentially abandoned as it was apparently an upstream problem.

Not a lot has happened since, but this post provides some hope that tvheadend devs are willing to look at it.

Maybe if we could get a rebuild of the tvheadend server addon which includes this patch, some useful information might be provided to the devs which could help resolve the problem.

Is this possible?
Does anyone have the time and capability to do this?

I am very willing to test if it can be done.

Thank you.

(the old thread is closed so apologies for starting a new one)