Tvheadend

Attach the unmodified file.

Is there any update on this problem?

An older Linux install of tvheadend and that does not have the problem

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

Current ARM build for Coreelec which does

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)

An older Linux install of tvheadend that does not have the problem

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

Current ARM build for Coreelec which does

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)

Do you see line 'parsed Enigma%d bouquet %s (%d services)' (the %d/%s will be replaced with the correct numbers/text) in the log ?

0xFFFF0000 hash is for DVB-C, so you need to have the service in the DVB-C network with the correct sid/tsid/onid in the tvheadend's database, for example:

#DESCRIPTION BBC ONE HD
#SERVICE 1:0:1:28A7:68:F020:FFFF0000:0:0:0:

1:        item type - value 1 is only allowed
0:        0 - service, 64 - label
1:        service type
28A7:     service id (sid), dec - 10407
68:       transpoder id (tsid), dec - 104
F020:     network id (onid), dec - 61472
FFFF0000: DVB-C network
0:
0:
0:

0xFFFF0000 hash is for DVB-C,

What would be the hash for DVB-T?

(I don't have Enigma)

I am trying to determine if the problem I am seeing is due to some change in how tvheadend handles my DVB-T bouquet list, or if the problem is due to the environment (OS), build version or maybe build type (ARM/Linux).

I have a separate bouquet for the few DVB-T channels available to me, which works without issues in

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

on my main Linux install.

That same bouquet does not function on my ARM device running CoreElec JeOS

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 complete bouquet file content is

#NAME   - -  DVB-T TV --

"Number": 1
#DESCRIPTION "RTÉ One" 
#SERVICE 1:0:1:835:3EA:2174:EEEE0000:0:0:0:

"Number": 2
#DESCRIPTION "RTÉ2" 
#SERVICE 1:0:1:44E:3E9:2174:EEEE0000:0:0:0:

"Number": 3
#DESCRIPTION "Virgin Media 1" 
#SERVICE 1:0:1:44F:3E9:2174:EEEE0000:0:0:0:

"Number": 4
#DESCRIPTION "Virgin Media 2" 
#SERVICE 1:0:1:452:3E9:2174:EEEE0000:0:0:0:

"Number": 5
#DESCRIPTION "Virgin Media 3" 
#SERVICE 1:0:1:837:3EA:2174:EEEE0000:0:0:0:

"Number": 6
#DESCRIPTION "TG4" 
#SERVICE 1:0:1:450:3E9:2174:EEEE0000:0:0:0:

"Number": 7
#DESCRIPTION "RTÉ Junior" 
#SERVICE 1:0:1:83B:3EA:2174:EEEE0000:0:0:0:

"Number": 8
#DESCRIPTION "RTÉ One +1" 
#SERVICE 1:0:1:83F:3EA:2174:EEEE0000:0:0:0:

"Number": 9
#DESCRIPTION "RTÉ News Now" 
#SERVICE 1:0:1:451:3E9:2174:EEEE0000:0:0:0:

"Number": 10
#DESCRIPTION "Tithe an Oireachtais" 
#SERVICE 1:0:1:44D:3E9:2174:EEEE0000:0:0:0:

I have since tried using LibreElec and OSMC on a R-Pi 2, and the same problem appeared.

You don't follow my questions, so I cannot help you. Tvheadend must have the services with matching IDs available (scanned). Hashes are FFFF0000 DVB-C, EEEE0000 DVB-T, DDDD0000 ATSC.

You don't follow my questions, so I cannot help you. Tvheadend must have the services with matching IDs available (scanned). 
Hashes are FFFF0000 DVB-C, EEEE0000 DVB-T, DDDD0000 ATSC.

I thought I had, sorry.
My DVB-T entries have this format

#SERVICE 1:0:1:835:3EA:2174:EEEE0000:0:0:0:

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

The same file will not work in the new build on the ARM devices I have tried.

Has the format needed changed for the bouquet file, or is there some other reason this no longer works?

Thank you for the assistance.

I don't know if this is helpful or not ...... this is what is shown in the tvheadend log when I attempt to enable my DVB-T Bouquet

2018-12-21 15:46:03.008 mpegts: 690MHz in DVB-T - tuning on HDHomeRun DVB-T Tuner #3 (192.168.1.2)
2018-12-21 15:46:03.008 tvhdhomerun: tuning to t8qam64:690000000
2018-12-21 15:46:03.036 subscription: 0003: "epggrab" subscribing to mux "690MHz", weight: 4, adapter: "HDHomeRun DVB-T Tuner #3 (192.168.1.2)", network: "DVB-T", service: "Raw PID Subscription" 
2018-12-21 15:50:41.348 subscription: 0003: "epggrab" unsubscribing
2018-12-21 15:51:03.789 bouquet: parsed Enigma2 bouquet   My DBV-T (0 services)

As you can see it returns zero services.

Yes, so again, do you have service 1:0:1:835:3EA:2174:EEEE0000 scanned (present the service grid - webui?). Look for decimal numbers using the conversion table in my comment number 6.

Jaroslav Kysela wrote:

Yes, so again, do you have service 1:0:1:835:3EA:2174:EEEE0000 scanned (present the service grid - webui?). Look for decimal numbers using the conversion table in my comment number 6.

I guess I do not understand correctly what information you are asking me for .... sorry.

This couple of pics might help explain what I see

Manually mapped Service RTÉ One

Tuners locked

tvheadend log

2018-12-22 14:47:59.402 bouquet: parsed Enigma2 bouquet My DVB-S (126 services)
2018-12-22 14:47:59.403 bouquet: parsed Enigma2 bouquet My DVB-T (0 services)

I should also make it clear (don't think I did previously) that I have no difficulty manually mapping the DVB-T channels.
It is the auto-mapping that is failing ..... apparently due to tvheadend failing to parse the DVB-T bouquet.

This same bouquet file is used successfully on my x86_64 install as explained in #8 above.

It is probable that I still have not provided exactly what you are looking for ... if not maybe you could provide some brief instruction how to acquire that info, thanks.

My question in comment number 6 was to verify, if the service with the given parameters exist in your tvh. So, parse one line you're trying to import manually - get the decimal numbers and verify if the 'Service ID', 'Transpodender ID', 'Network ID' matches a detected (scanned) service in your tvh - service grid / mux grid in webui.

Jaroslav Kysela wrote:

My question in comment number 6 was to verify, if the service with the given parameters exist in your tvh. So, parse one line you're trying to import manually - get the decimal numbers and verify if the 'Service ID', 'Transpodender ID', 'Network ID' matches a detected (scanned) service in your tvh - service grid / mux grid in webui.

Yes they do.
835:3EA:2174 confirmed 2101 : 1002 : 8564

and as already stated the channels can be manually mapped in the Arm device and will auto-map in the X86_64 device, all using the exact same bouquet file, and feeding from the same tuner.

The question is ... is this a bug in tvheadend or a bug in the Arm build I am using?

Has anything like this been reported previously? It might well be a bug in the Arm build I am using.

Are there any thoughts on this?

Is it a tvheadend bug or a bug in the ARM build I am using?

If that could be determined then at least I would know where to look to seek a resolution.

Thanks.

You may check the code yourself: https://github.com/tvheadend/tvheadend/blob/release/4.2/src/input/mpegts/mpegts_service.c#L653 . It's pretty straight.

Jaroslav Kysela wrote:

You may check the code yourself: https://github.com/tvheadend/tvheadend/blob/release/4.2/src/input/mpegts/mpegts_service.c#L653 . It's pretty straight.

It might well be simple code but unfortunately I do not have the knowledge to read and understand it.

For that I am dependent on others.

Jaroslav Kysela wrote:

You may check the code yourself: https://github.com/tvheadend/tvheadend/blob/release/4.2/src/input/mpegts/mpegts_service.c#L653 . It's pretty straight.

It might well be simple code but unfortunately I do not have the knowledge to read and understand it.

For that I am dependent on others.

But ..... if that same code is used both on X86_64 builds and ARM builds, then the problem is hardly in that code, as the problem only appears in the ARM build apparently.

Adding more info to the problem, it appears that it is unable to complete the task of mapping services i get the following error:

mpegts: too much queued table input data (over 2MB) for Sony CXD2837ER DVB-T/T2/C demodulator #0 : DVB-C #0, discarding new

Just to update that the problem is still present on

Build: 4.2.7-34

Is someone looking into this presently?
Any feedback to report?

Change code like this way and show the log for e2 import:

diff --git a/src/input/mpegts/mpegts_service.c b/src/input/mpegts/mpegts_service.c
index d6f26e066..f830273a4 100644
--- a/src/input/mpegts/mpegts_service.c
+++ b/src/input/mpegts/mpegts_service.c
@@ -667,13 +667,16 @@ mpegts_service_find_e2(uint32_t stype, uint32_t sid, uint32_t tsid,
   case 0xDDDD0000: idc = &dvb_mux_dvbt_class; break;
   default:         idc = &dvb_mux_dvbs_class; break;
   }
+  tvhdebug(LS_MPEGTS, "find e2 %u %u %u %u %08x", stype, sid, tsid, onid, hash);
   LIST_FOREACH(mn, &mpegts_network_all, mn_global_link) {
     if (!idnode_is_instance(&mn->mn_id, &dvb_network_class)) continue;
     if (dvb_network_mux_class(mn) != idc) continue;
     if (!mpegts_service_match_network(mn, hash, idc)) continue;
+    tvhdebug(LS_MPEGTS, "find e2 network found");
     LIST_FOREACH(mm, &mn->mn_muxes, mm_network_link) {
       if (!idnode_is_instance(&mm->mm_id, idc)) continue;
       if (mm->mm_tsid != tsid || mm->mm_onid != onid) continue;
+      tvhdebug(LS_MPEGTS, "tsid / onid found");
       if (!mpegts_service_match_mux((dvb_mux_t *)mm, hash, idc)) continue;
       LIST_FOREACH(s, &mm->mm_services, s_dvb_mux_link)
         if (s->s_dvb_service_id == sid)

Thank you for posting the above patch.
Unfortunately I am not a developer and don't build from source. :(

If someone does build a version with this I am very willing to test and report back results if that would help.

Pure Isle wrote:

Thank you for posting the above patch.
Unfortunately I am not a developer and don't build from source. :(

If someone does build a version with this I am very willing to test and report back results if that would help.

What OS? Do you only need binary?

Pablo R. wrote:

Pure Isle wrote:

Thank you for posting the above patch.
Unfortunately I am not a developer and don't build from source. :(

If someone does build a version with this I am very willing to test and report back results if that would help.

What OS? Do you only need binary?

I am using LibreElec on R-Pi 2 and CoreElec on an Amlogic S905w Tanix Tx3.

Ideally I would like a Tvheadend-server plugin for Kodi which I use on both OSs.

I am using the latest Beta of Kodi 18 (Leia) in those OSs.
The OSs are closely related and the same addon is used in both at present, as far as I can determine.

Do you think you could help?
Thanks for your interest.

A kind soul on the CoreElec forum built the addon for me and here are the results from the tvheadend service log, with only the DVB-T Quad HDHomerun tuners enabled.

2019-01-15 20:01:27.626 [   INFO] main: Log started
2019-01-15 20:01:27.717 [   INFO] http: Starting HTTP server 0.0.0.0:9981
2019-01-15 20:01:27.721 [   INFO] htsp: Starting HTSP server 0.0.0.0:9982
2019-01-15 20:01:27.736 [   INFO] config: loaded
2019-01-15 20:01:27.740 [   INFO] config: scanfile (re)initialization with path <none>
2019-01-15 20:01:28.445 [   INFO] dvr: Creating new configuration ''
2019-01-15 20:01:28.449 [   INFO] descrambler: adding CAID 2600 as constant crypto-word (BISS)
2019-01-15 20:01:28.449 [   INFO] epggrab: module eit created
2019-01-15 20:01:28.449 [   INFO] epggrab: module uk_freesat created
2019-01-15 20:01:28.449 [   INFO] epggrab: module uk_freeview created
2019-01-15 20:01:28.449 [   INFO] epggrab: module nz_freeview created
2019-01-15 20:01:28.449 [   INFO] epggrab: module viasat_baltic created
2019-01-15 20:01:28.449 [   INFO] epggrab: module Bulsatcom_39E created
2019-01-15 20:01:28.449 [   INFO] epggrab: module psip created
2019-01-15 20:01:28.462 [   INFO] epggrab: module opentv-ausat created
2019-01-15 20:01:28.462 [   INFO] epggrab: module opentv-skynz created
2019-01-15 20:01:28.463 [   INFO] epggrab: module opentv-skyit created
2019-01-15 20:01:28.465 [   INFO] epggrab: module opentv-skyuk created
2019-01-15 20:01:28.467 [   INFO] epggrab: module pyepg created
2019-01-15 20:01:28.467 [   INFO] epggrab: module xmltv created
2019-01-15 20:01:28.470 [   INFO] spawn: Executing "/storage/.kodi/addons/service.tvheadend42/bin/tv_grab_file" 
2019-01-15 20:01:28.478 [   INFO] epggrab: module /storage/.kodi/addons/service.tvheadend42/bin/tv_grab_file created
2019-01-15 20:01:28.485 [ NOTICE] START: HTS Tvheadend version 4.2.7-34 ~ CoreELEC Tvh-addon v9.0.117 started, running as PID:2569 UID:0 GID:39, CWD:/ CNF:/storage/.kodi/userdata/addon_data/service.tvheadend42
2019-01-15 20:01:28.491 [   INFO] bouquet: parsed Enigma2 bouquet My_DVB-T  (0 services)
2019-01-15 20:01:30.874 [   INFO] avahi: Service 'Tvheadend' successfully established.
2019-01-15 20:01:32.222 [   INFO] scanfile: DVB-S - loaded 1 regions with 113 networks
2019-01-15 20:01:32.223 [   INFO] scanfile: DVB-T - loaded 44 regions with 1127 networks
2019-01-15 20:01:32.223 [   INFO] scanfile: DVB-C - loaded 18 regions with 60 networks
2019-01-15 20:01:32.223 [   INFO] scanfile: ATSC-T - loaded 2 regions with 12 networks
2019-01-15 20:01:32.223 [   INFO] scanfile: ATSC-C - loaded 1 regions with 5 networks
2019-01-15 20:01:32.223 [   INFO] scanfile: ISDB-T - loaded 2 regions with 1297 networks
2019-01-15 20:01:35.796 [   INFO] htsp: Got connection from 192.168.1.6
2019-01-15 20:01:35.815 [   INFO] htsp: 192.168.1.6: Welcomed client software: Kodi Media Center (HTSPv34)
2019-01-15 20:01:35.817 [   INFO] htsp: 192.168.1.6 [ Kodi Media Center ]: Identified as user ''
2019-01-15 20:01:44.806 [   INFO] tvhdhomerun: Found HDHomerun device 12501fa9 with 4 tuners
2019-01-15 20:01:44.836 [   INFO] tvhdhomerun: Using Network type : DVB-T
2019-01-15 20:01:44.839 [   INFO] tvhdhomerun: Created frontend 12501FA9 tuner 0
2019-01-15 20:01:44.841 [   INFO] tvhdhomerun: Created frontend 12501FA9 tuner 1
2019-01-15 20:01:44.842 [   INFO] tvhdhomerun: Created frontend 12501FA9 tuner 2
2019-01-15 20:01:44.844 [   INFO] tvhdhomerun: Created frontend 12501FA9 tuner 3

Unfortunately I don't think there is very much of interest there (but what would I know?). Should there have been more?
Still no services found in the bouquet.

2019-01-15 20:01:28.485 [ NOTICE] START: HTS Tvheadend version 4.2.7-34 ~ CoreELEC Tvh-addon v9.0.117 started, running as PID:2569 UID:0 GID:39, CWD:/ CNF:/storage/.kodi/userdata/addon_data/service.tvheadend42
2019-01-15 20:01:28.491 [   INFO] bouquet: parsed Enigma2 bouquet My_DVB-T  (0 services)

Thanks.

Enable debug log (through webui or to a file) and trigger the bouquet scan to see more.

Jaroslav Kysela wrote:

Enable debug log (through webui or to a file) and trigger the bouquet scan to see more.

With the device running and the DVB-T bouquest not selected I enabled debug mode.
There were no entries in the log of the webUI at that time.
After I enabled debug mode I enabled the DVB-T bouquet and the output is this

Loglevel debug: enabled

2019-01-16 19:52:50.037 bouquet: parsed Enigma2 bouquet My_DVB-T  (0 services)

2019-01-16 19:53:51.519 bouquet: parsed Enigma2 bouquet My_DVB-S  (128 services)

2019-01-16 19:53:53.000 epgdb: snapshot start

2019-01-16 19:53:53.173 epgdb: queued to save (size 2691560)

2019-01-16 19:53:53.173 epgdb:   brands     0

2019-01-16 19:53:53.173 epgdb:   seasons    786

2019-01-16 19:53:53.173 epgdb:   episodes   4730

2019-01-16 19:53:53.173 epgdb:   broadcasts 5206

2019-01-16 19:53:53.175 epgdb: save start

2019-01-16 19:53:53.347 epgdb: stored (size 444887)

2019-01-16 19:55:55.931 epggrab: PSIP: ATSC Grabber - data completion timeout for 12207V in DVB-S Network

2019-01-16 19:55:55.931 epggrab: Bulsatcom: Bula 39E - data completion timeout for 12207V in DVB-S Network

2019-01-16 19:55:55.931 epggrab: VIASAT: Baltic - data completion timeout for 12207V in DVB-S Network

2019-01-16 19:55:55.931 epggrab: UK: Freesat - data completion timeout for 12207V in DVB-S Network

2019-01-16 19:55:55.931 epggrab: EIT: DVB Grabber - data completion timeout for 12207V in DVB-S Network

2019-01-16 19:55:55.931 subscription: 01FB: "epggrab" unsubscribing

2019-01-16 19:55:56.929 mpegts: 12246V in DVB-S Network - tuning on SAT>IP DVB-S Tuner #4 (192.168.1.106)

2019-01-16 19:55:56.930 subscription: 0202: "epggrab" subscribing to mux "12246V", weight: 4, adapter: "SAT>IP DVB-S Tuner #4 (192.168.1.106)", network: "DVB-S Network", service: "Raw PID Subscription" 

2019-01-16 19:56:06.929 mpegts: 12246V in DVB-S Network - scan no data, failed

2019-01-16 19:56:36.929 subscription: 0202: "epggrab" unsubscribing

2019-01-16 19:56:37.930 mpegts: 12246V in DVB-S Network - tuning on SAT>IP DVB-S Tuner #4 (192.168.1.106)

2019-01-16 19:56:37.930 subscription: 0205: "epggrab" subscribing to mux "12246V", weight: 4, adapter: "SAT>IP DVB-S Tuner #4 (192.168.1.106)", network: "DVB-S Network", service: "Raw PID Subscription" 

2019-01-16 19:57:06.982 mpegts: 12246V in DVB-S Network scan complete

I believe I did have debug enabled for my previous report, but never mentioned it, sorry.

It appears that my extended log changes from comment 23 are not applied to the source code. The tvhdebug() call might be freely changed to tvhinfo() call to not bother with the debug log enabling.

You want to try a different patch?

Has any dev been able to duplicate this problem?

Is there a solution forthcoming?

It appears a solution has been proposed

https://github.com/tvheadend/tvheadend/pull/1303

It works here.