100% CPU whilst epggrab or scanning muxes, unresponsive/dead shortly after

Hi guys!

I've running a tvheadend 4.3-1952~gb824e237e setup on arch linux running since a year or so. It's quite simple setup - tvheadend is using 4 satip tuners of a Telestar Digibit R1 connected to a static antenna pointing to Astra 19.2E.

But since some days its periodically freezing with 1 thread @ 100% cpu. I could narrow it down to epggrab or scanning a network.
At first it's getting unresponsive, but I can still use the webinterface to check what it's doing. It's ALWAYS having a subscription being in state "BAD" - that one is hanging for some seconds/minutes and then 1 thread is going 100% cpu, blocking the whole software.

The BAD subscription is trying to scan/epg a MUX that is 1) not available on ASTRA anymore or 2) cannot be tuned as of bad signal

I have loads of logging things in syslog - not sure where it's starting to die:

Feb 25 02:04:00 redarch tvheadend[1514]: mpegts: 11244H in Astra - tuning on SAT>IP DVB-S Tuner #1 (10.48.80.10@UDP)
Feb 25 02:04:00 redarch tvheadend[1514]: satip: SAT>IP DVB-S Tuner #1 (10.48.80.10@UDP) - starting 11244H in Astra
Feb 25 02:04:00 redarch tvheadend[1514]: mpegts: 11244H in Astra - started
Feb 25 02:04:00 redarch tvheadend[1514]: tbl-eit: eit: grab started
Feb 25 02:04:00 redarch tvheadend[1514]: mpegts: 11244H in Astra - open PID 0012 (18) [20/0x7f44f4017a20]
Feb 25 02:04:00 redarch tvheadend[1514]: tbl-eit: eit: installed table handler (pid 18)
Feb 25 02:04:00 redarch tvheadend[1514]: mpegts: 11244H in Astra - open PID tables subscription [0042/0x7f44f4012600]
Feb 25 02:04:00 redarch tvheadend[1514]: subscription: 0016: "epggrab" subscribing to mux "11244H", weight: 4, adapter: "SAT>IP DVB-S Tuner #1 (10.48.80.10@UDP)", network: "Astra", service: "Raw PID Subscription" 
...
Feb 25 02:04:01 redarch tvheadend[1514]: service: 11244H in Astra: Status changed to [Tuning failed]
...
Feb 25 02:04:10 redarch tvheadend[1514]: subscription: 001B: "epggrab" subscribing to mux "11493.75H", weight: 4, adapter: "SAT>IP DVB-S Tuner #4 (10.48.80.10@UDP)", network: "Astra", service: "Raw PID Subscription" 
Feb 25 02:04:10 redarch tvheadend[1514]: epggrab: no OTA modules active for 11523.25H in Astra, check again next time
Feb 25 02:04:10 redarch tvheadend[1514]: epggrab: no OTA modules active for 11523.25H in Astra, check again next time
Feb 25 02:04:10 redarch tvheadend[1514]: epggrab: no OTA modules active for 11523.25H in Astra, check again next time
Feb 25 02:04:10 redarch tvheadend[1514]: epggrab: no OTA modules active for 11552.75H in Astra, check again next time
Feb 25 02:04:10 redarch tvheadend[1514]: epggrab: no OTA modules active for 11553H in Astra, check again next time
Feb 25 02:04:10 redarch tvheadend[1514]: mpegts: 11582.25H in Astra - add raw service
...
Feb 25 02:04:10 redarch tvheadend[1514]: service: 11244H in Astra: Status changed to [CA check] [Tuning failed] [Graceperiod expired] [Data timeout]
...
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat: bouquet 1040 (4160) [ARD Digital]
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat:  onid 0001 (1) tsid 0431 (1073) mux 11493.75H in Astra
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat:    service 6E2D (28205) type 01 (1)
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat:    service 6E2E (28206) type 01 (1)
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat:    service 6E40 (28224) type 01 (1)
...

It's ending with (but I'm sure that's just an aftereffect):

Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat:  onid 0001 (1) tsid 03EE (1006) mux 11273.25H in Astra
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat:    service 1086 (4230) type 19 (25)
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat:  onid 0001 (1) tsid 0436 (1078) mux 11273.25H in Astra
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat:    service 6FED (28653) type 19 (25)
Feb 25 02:04:11 redarch tvheadend[1514]: tbl-base: bat: completed pid 17 table 00000048 / 000000f8
Feb 25 02:04:36 redarch tvheadend[1514]: mpegts: too much queued table input data (over 2MB) for SAT>IP DVB-S Tuner, discarding new

Good thing: i can repoduce it immediately.
Bad thing: I've got no idea what to to - hope you guys can help me :-)

I don't understand what happened - can this simply be a cause of bad signal? But I guess the software shouldn use 100% CPU only just because of bad signal or non-existing muxes?!

Thanks in advance,
Lukas

Replies (2)

RE: 100% CPU whilst epggrab or scanning muxes, unresponsive/dead shortly after - Added by luke red over 2 years ago

At the risk of this becoming a monologue: today I tried deleting all muxes I hadn't used at all (sort by "mapped channels" and delete all w/ 0-value).
After deleting, tvheadend immediately started searching the network. I recognized I had "new + changed muxes" setting enabled. At a first glance it looks as if a lot of muxes still have FAIL as status, but the "EPGscan" flag is also gone now. This will for sure make a difference.

Not sure if it helps - I'll simply wait 1-2 days and see if it died again. If not, I think I'll again delete all the muxes but before set tvheadend not to search for new muxes...

Lukas

RE: 100% CPU whilst epggrab or scanning muxes, unresponsive/dead shortly after - Added by luke red over 2 years ago

I had to disable epg scan for 3 of 4 tuners, but now it's stable again.
So sequentially scanning, not parallel any more.

Still no idea why it worked 2 years without any issues before suddenly breaking down every day.

Signal strength/quality might have changed (lowered), as I had re-adjusted the dish some day in winter. Unfortunately the problem wasn't the dish itself, but snow hanging down the gutter :-D

(1-2/2)

Project

General

Profile

Tvheadend