Project

General

Profile

Bug #4584

Bug #4851: TVH freezes: mpegts: too much queued table input data (over 2MB), discarding new

100% CPU hang after - mpegts: too much queued table input data (over 2MB), discarding new

Added by Anthony Thomas over 2 years ago. Updated about 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2017-09-10
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-435~gaa052ac
Affected Versions:

Description

I've very recently come across the issues where I get the error

mpegts: too much queued table input data (over 2MB), discarding new

From what I've read this is caused by a lack of available CPU (?) which causes issues with TVHeadend.
I seem to have pinpointed the cause - possibly the CrashPlan backup software as that is the only change on my system I know it is CPU and RAM hungry. Changed plans and now have a "Pro" account, but the software has actually remained the same.

This was occuring with version - tvheadend_4.3-279~gdaa5a1e_amd64.deb
And now - tvheadend_4.3-435~gaa052ac_amd64.deb

System
Ubuntu 14.04.5
CPU - Intel Pentium G3258 @ 3.20GHz
RAM - 8GB

Digibit R1 - SAT>IP server

This can happen at any time, even when I'm not watching anything, I assume when epggrab is working away.

If I need to ensure more CPU for TVH then fair enough, but the issue is that when this occurs TVH itself grabs 100% and crashes, requiring it to be killed and restarted, taking the EPG database with it.

Any suggestions?
What logs do you want?


Files

History

#1

Updated by Jaroslav Kysela over 2 years ago

1) look to log which muxes are tuned when 2MB messages are printed
2) use 'top -H' to look which thread uses 100% CPU

#2

Updated by Anthony Thomas over 2 years ago

Jaroslav Kysela wrote:

1) look to log which muxes are tuned when 2MB messages are printed
2) use 'top -H' to look which thread uses 100% CPU

http://paste.ubuntu.com/25515821/

That's quite a lengthy log - it tripped up last night at 02:06 and it looks like it was when there was epg updating going on.

I'll check specific threads next time it happens.

#3

Updated by Jaroslav Kysela over 2 years ago

Perhaps, you can try to disable position 28.2E . There seems to be an issue with the freeview or dvbsky data parsers.

#4

Updated by Anthony Thomas over 2 years ago

Jaroslav Kysela wrote:

Perhaps, you can try to disable position 28.2E . There seems to be an issue with the freeview or dvbsky data parsers.

Unfortunately I watch most of my TV on 28.2E, and this seems to only be a recent issue.

Screenshot attached of top -H
tvh:satip-front is the culprit.

Should it be taking 100% when it encounters this issue?

#5

Updated by Jaroslav Kysela over 2 years ago

It seems like a new issue. It would be nice if you could you play with gdb to look what's in loop in the tvh:satip-front thread. https://tvheadend.org/projects/tvheadend/wiki/Debugging#Dead-or-Live-Lock

#6

Updated by C vH over 2 years ago

just saying that I had the "same" problem at current 4.2.x stable

Sep 13 10:37:38 satserver tvheadend1113: mpegts: too much queued table input data (over 2MB), discarding new

sadly no idea how to trigger it - issue popped up after ~10 days uptime

#7

Updated by Anthony Thomas over 2 years ago

I haven't had chance to do the debugging yet.

But what I did do is install TVH on a totally separate system, different hardware - using the unstable repo rather than building myself.

Intel Atom 330/Nvidia ION
2GB RAM
Ubuntu 17.04 - Zesty
Running Xenial TVH unstable repo

I copied over the config from the original TVH system and unfortunately it has had the same issue overnight. I'll wipe this config and build up the elements to see if I can find specifically what triggers it, or it could just be an epg issue as it seems to happen when (but not always) when the epg is being scraped OTA.

Across two logs
http://paste.ubuntu.com/25528769/
http://paste.ubuntu.com/25528770/

#8

Updated by Jaroslav Kysela about 2 years ago

  • Status changed from New to Rejected
  • Parent task set to #4851

Closing as dup of #4851 .

Also available in: Atom PDF