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
0%
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
Updated by Jaroslav Kysela about 7 years ago
Updated by 1) look to log which muxes are tuned when 2MB messages are printed
2) use 'top -H' to look which thread uses 100% CPU
Updated by Anthony Thomas about 7 years ago
Updated by 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.
Updated by Jaroslav Kysela about 7 years ago
Perhaps, you can try to disable position 28.2E . There seems to be an issue with the freeview or dvbsky data parsers.
Updated by Anthony Thomas about 7 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?
Updated by Jaroslav Kysela about 7 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
Updated by C vH about 7 years ago
Updated by 
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
Updated by Anthony Thomas about 7 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/
Updated by Jaroslav Kysela almost 7 years ago
- Status changed from New to Rejected
- Parent task set to #4851
Closing as dup of #4851 .