Bug #5387
External Bouquet for DVB-C/T does not see any services
0%
Description
DVB-C/T services are not seen or mapped. File specified as file:///storage/.kodi/myfav.tv
File format as follows:
#NAME MyFav
#DESCRIPTION Channel
#SERVICE 1:0:1:X91:90:X090:XXXX0000:0:0:0:
#DESCRIPTION Channel
#SERVICE 1:0:1:9X9:19:X090:XXXX0000:0:0:0:
#DESCRIPTION Channel
#SERVICE 1:0:1:XXX:99:X090:XXXX0000:0:0:0:
#DESCRIPTION Channel
#SERVICE 1:0:1:X99:99:X090:XXXX0000:0:0:0:
#DESCRIPTION Channel
#SERVICE 1:0:1:909:19:X090:XXXX0000:0:0:0:
#DESCRIPTION Channel
#SERVICE 1:0:1:X99:1X:X090:XXXX0000:0:0:0:
#DESCRIPTION Channel
#SERVICE 1:0:1:X91:1X:X090:XXXX0000:0:0:0:
#DESCRIPTION Channel
#SERVICE 1:0:1:9XX:19:X090:XXXX0000:0:0:0:
#DESCRIPTION Channel
#SERVICE 1:0:1:991:19:X090:XXXX0000:0:0:0:
Files
History
Updated by M Fizz almost 6 years ago
- File Channels.tv Channels.tv added
Jaroslav Kysela wrote:
Attach the unmodified file.
See attached
Updated by Pure Isle almost 6 years ago
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)
Updated by Pure Isle almost 6 years ago
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)
Updated by Jaroslav Kysela almost 6 years ago
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:
Updated by Pure Isle almost 6 years ago
0xFFFF0000 hash is for DVB-C,
What would be the hash for DVB-T?
(I don't have Enigma)
Updated by Pure Isle almost 6 years ago
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:
Updated by Pure Isle almost 6 years ago
I have since tried using LibreElec and OSMC on a R-Pi 2, and the same problem appeared.
Updated by Jaroslav Kysela almost 6 years ago
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.
Updated by Pure Isle almost 6 years ago
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:
which work in my desktop build
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.
Updated by Pure Isle almost 6 years ago
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.
Updated by Jaroslav Kysela almost 6 years ago
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.
Updated by Pure Isle almost 6 years ago
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.
Updated by Jaroslav Kysela almost 6 years ago
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.
Updated by Pure Isle almost 6 years ago
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.
Updated by Pure Isle almost 6 years ago
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.
Updated by Jaroslav Kysela almost 6 years ago
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.
Updated by Pure Isle almost 6 years ago
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.
Updated by Pure Isle almost 6 years ago
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.
Updated by M Fizz almost 6 years ago
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
Updated by Pure Isle almost 6 years ago
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?
Updated by Jaroslav Kysela almost 6 years ago
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)
Updated by Pure Isle almost 6 years ago
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.
Updated by Pablo R. almost 6 years ago
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?
Updated by Pure Isle almost 6 years ago
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.
Updated by Pure Isle almost 6 years ago
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.
Updated by Jaroslav Kysela almost 6 years ago
Enable debug log (through webui or to a file) and trigger the bouquet scan to see more.
Updated by Pure Isle almost 6 years ago
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.
Updated by Jaroslav Kysela almost 6 years ago
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.
Updated by Pure Isle almost 6 years ago
Has any dev been able to duplicate this problem?
Is there a solution forthcoming?
Updated by Pure Isle about 5 years ago
It appears a solution has been proposed
https://github.com/tvheadend/tvheadend/pull/1303
It works here.