Bug #5261
Stop mapping services for device SW update channel via DVBC
0%
Description
I am in the Netherlands in Ziggo domain. Ziggo provides services for software updates for supported devices (e.g. Humax 5000 or several Samsung xxxx). When I take a look at these services, they all have service type 128. When I start mapping services, tvheadend tries to map these as well, which has no use.
Currently tvheadend hangs on mapping these services, which makes it impossible to map services at all!
Is it possible to block this service type 128 from mapping services?
tvheadend is running on Raspbian Stretch
Files
History
Updated by Jaroslav Kysela about 6 years ago
Could you explain a bit more what hangs? Debug log might give a clue.
Updated by Klara Jansen about 6 years ago
Jaroslav Kysela wrote:
Could you explain a bit more what hangs? Debug log might give a clue.
I'm not sure which debug subsystems to start (I used: main,muxer,service,channel,service-mapper), so I am not sure if this tells you anything. Please advise if you need other information!
For this test, I selected 3 channels: 2 regular TV channels and 1 on which tvheadend fails (Humax 5300 dev) and selected: 'map selected services'. tvheadend starts with mapping the last but never continues to the next channel. The progress bar in the status screen shows: 0 / 3, but no progress as well
2018-10-21 12:25:56.222 [ INFO]:service-mapper: starting 2018-10-21 12:25:56.222 [ INFO]:service-mapper: checking Ziggo/474MHz/Humax 5300 dev 2018-10-21 12:25:56.222 [ INFO]:service-mapper: waiting for input 2018-10-21 12:25:56.222 [ DEBUG]:service: 3: Ziggo/474MHz/Humax 5300 dev si 0x73f11140 DRXK DVB-C DVB-T : DVB-C #0 weight 4 prio 10 error 0 (OK) 2018-10-21 12:25:56.222 [ INFO]:mpegts: 474MHz in Ziggo - tuning on DRXK DVB-C DVB-T : DVB-C #0 2018-10-21 12:25:56.226 [ INFO]:subscription: 006B: "epggrab" unsubscribing 2018-10-21 12:25:56.407 [ INFO]:subscription: 006D: "service_mapper" subscribing to service "Ziggo/474MHz/Humax 5300 dev", weight: 7, adapter: "DRXK DVB-C DVB-T : DVB-C #0", network: "Ziggo", mux: "474MHz", provider: "Ziggo", client="service_mapper" 2018-10-21 12:25:56.826 [ DEBUG]:service: Ziggo/474MHz/Humax 5300 dev: Status changed to [Hardware input] 2018-10-21 12:25:56.826 [ DEBUG]:service: Ziggo/474MHz/Humax 5300 dev: Status changed to [Hardware input] [Input on service] 2018-10-21 12:25:56.826 [ DEBUG]:service: Ziggo/474MHz/Humax 5300 dev: Status changed to [Hardware input] [Input on service] [Demuxed packets] 2018-10-21 12:25:56.826 [ DEBUG]:service: Ziggo/474MHz/Humax 5300 dev: Status changed to [Hardware input] [Input on service] [Demuxed packets] [Reassembled packets] 2018-10-21 12:25:57.227 [ DEBUG]:service: 3: 626MHz in Ziggo si 0x73f2f548 DRXK DVB-C DVB-T : DVB-C #0 weight 7 prio 10 error 0 (OK) 2018-10-21 12:25:58.325 [ DEBUG]:service: Ziggo/474MHz/Humax 5300 dev: Status changed to [Hardware input] [Input on service] [Demuxed packets] [Reassembled packets] [CA check] 2018-10-21 12:27:01.229 [ DEBUG]:service: 3: 626MHz in Ziggo si 0x73f15c28 DRXK DVB-C DVB-T : DVB-C #0 weight 7 prio 10 error 0 (OK) 2018-10-21 12:27:28.636 [ DEBUG]:service: 3: 626MHz in Ziggo si 0x73f5ac78 DRXK DVB-C DVB-T : DVB-C #0 weight 7 prio 10 error 0 (OK) 2018-10-21 12:28:32.636 [ DEBUG]:service: 3: 626MHz in Ziggo si 0x73f26f60 DRXK DVB-C DVB-T : DVB-C #0 weight 7 prio 10 error 0 (OK)
Updated by Jaroslav Kysela about 6 years ago
--trace service,subscription,service-mapper - https://tvheadend.org/projects/tvheadend/wiki/Traces
Updated by Klara Jansen about 6 years ago
Jaroslav Kysela wrote:
--trace service,subscription,service-mapper - https://tvheadend.org/projects/tvheadend/wiki/Traces
Hope this helps...
Updated by Klara Jansen about 6 years ago
Jaroslav Kysela wrote:
Could you retest with v4.3-1487-gef939ad18 ?
Tested. Scenario: I removed all muxes (and hence services), added the primary mux (474Mhz), waited for all muxes to be added (and status OK) and then mapped all services.
It's not stalling anymore. However: no service at all is mapped! So not even the FTA channels.
I ended up with:
Mapped: 0
Ignored: 28
Failed: 371
I also have an issue with two muxes that always end up in a failed situation. I'll create a new issue for that.
Updated by Klara Jansen about 6 years ago
Jaroslav Kysela wrote:
v4.3-1492-g476ed21c0 ?
The watchdog kicks in after 30 seconds, but the total time apparently is too long for the service mapper, as the website return to the default page. You need to (re)start the service mapper again. I'm not sure if this is the best solution. After the service-mapper has gone through all of these specific services, the other services are mapped correctly.
If I look into the details of the service, I can see that these have a specific service type of 128. I do not know if this is a general rule (or not). If so, isn't it easier to check for this service type and skip mapping if equal? Unfortunately, I am not a developer...
Updated by Jaroslav Kysela about 6 years ago
I tried to improve the code in v4.3-1494-g26dc2643e - there's a check for A/V streams after 5 seconds and the mapper breaks the loop when no A/V streams are detected in PMT.
Anyway, there is no timeout in webui - if you got the default page, it usually means that the whole tvheadend was restarted for a reason.
Updated by Klara Jansen about 6 years ago
Jaroslav Kysela wrote:
Anyway, there is no timeout in webui - if you got the default page, it usually means that the whole tvheadend was restarted for a reason.
What I mean is that the gui returns to the EPG page after a while. I have not restarted tvheadend. When then returning to the status page to look at the progress of the mapping process, it shows 0 / 0 and the Services tab confirms that no additional services are mapped.
I will give 1494 a try and get back to you
Updated by Klara Jansen about 6 years ago
Just tried 1494. tvheadend gui freezes. Syslog shows the following:
Oct 22 21:41:33 meter tvheadend[7976]: mpegts: too much queued input data (over 50MB) for DRXK DVB-C DVB-T : DVB-C #0, discarding new
If required, I will make a dump. But that will be tomorrow at least...
Updated by Klara Jansen about 6 years ago
Jaroslav Kysela wrote:
Locking issue: Try v4.3-1495-g7ad64f712.
Retested with 1495: works perfect! Thanks!
Updated by Jaroslav Kysela about 6 years ago
- Status changed from New to Fixed
Thanks for the feedback. Closing as fixed.