Project

General

Profile

Bug #5261

Stop mapping services for device SW update channel via DVBC

Added by Klara Jansen about 6 years ago. Updated about 6 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Service Mapping
Target version:
Start date:
2018-10-15
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1468~g3f74523d2
Affected Versions:

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

dump.txt (124 KB) dump.txt Klara Jansen, 2018-10-21 19:19
services (314 KB) services Mapping (most of the) services Klara Jansen, 2018-10-22 09:44

History

#1

Updated by Jaroslav Kysela about 6 years ago

Could you explain a bit more what hangs? Debug log might give a clue.

#2

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)
#3

Updated by Jaroslav Kysela about 6 years ago

--trace service,subscription,service-mapper - https://tvheadend.org/projects/tvheadend/wiki/Traces

#4

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

#5

Updated by Jaroslav Kysela about 6 years ago

Could you retest with v4.3-1487-gef939ad18 ?

#6

Updated by Jaroslav Kysela about 6 years ago

  • Target version set to 4.4
#7

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.

#8

Updated by Jaroslav Kysela about 6 years ago

v4.3-1492-g476ed21c0 ?

#9

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

#10

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.

#11

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

#12

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

#13

Updated by Jaroslav Kysela about 6 years ago

Locking issue: Try v4.3-1495-g7ad64f712.

#14

Updated by Klara Jansen about 6 years ago

Jaroslav Kysela wrote:

Locking issue: Try v4.3-1495-g7ad64f712.

Retested with 1495: works perfect! Thanks!

#15

Updated by Jaroslav Kysela about 6 years ago

  • Status changed from New to Fixed

Thanks for the feedback. Closing as fixed.

Also available in: Atom PDF