CPU usage and apparently epg grab

stultus Strebor

Hi,

I run TVH on an Intel Celeron CPU J1900 @ 1.99GHz, 4 cores, the cpu usage is usually in single figures for the whole server the hts process maybe a couple of percent.

However after what i suspect is an epg grab from freesat the usage sometimes rises to 60% or more and the TVH becomes unresponsive.

Typically the process runs for a couple of weeks, memory in use by hts will tick up from 300ish to over 700mb and again TVH becomes unresponsive.
I can log in and restart hts and away it goes.

The system is running 4.2.8-4~g9f7ab681a on Debian 9 Linux 4.9.0-8-amd64 on x86_64 but I've seen this behaviour before on earlier versions of hardware, OS and hts. I have no tuner hardware installed as i have a SATIP tuner.

Any ideas as to how I might track this down.

Regards Strebor

stultus Strebor

2019-01-28 14:04:10.160 [WARNING]:mpegts: too much queued table input data (over 2MB), discarding new

I see others with the same epg problem.
Is there anything to be done? config wise?

Can I reduce the number of tuners in use for the grab?

Strebor

stultus Strebor

I tried deleting the database but this made no difference.

Can I delete the otamux list, if so how is it recreated?

Regards Strebor

Saen Acro

Disable unused epg grabbers.

stultus Strebor

Only Freesat enabled !!

Jack Bamford

Ive seen a lot of people have this. Have you added the Freesat Home Mux? Ive noticed on my System that the Guide updates even when the EPG Grabber is not running.

stultus Strebor

Jack, 11425H was mapped but I did not add it explicitly.
I have forced a rescan and I'll see if that makes a difference.

Regards Strebor

Jack Bamford

On my App Server when the OTA Grabber is scheduled to run i have this wether its a scheduled or manually run.

subscription: 0354: "epggrab" subscribing to mux "11425H", weight: 4, adapter: "Montage Technology M88RS6000 : DVB-S #0", network: "Freesat HD", service: "Raw PID Subscription"

2019-01-28 02:04:01.470 linuxdvb: Unable to provide UNC value.

Could you attach your log info.

stultus Strebor

Well, the system has survived two scheduled epg grabs after a forced rescan.

I am presuming that there was a problem with one of the muxs, and that a weakness in the epg grab codes error handling was causing a problem.

thanks Strebor

Paul M

I've had this very problem for quite a while, I tried both stable and unstable.
I recently upgraded to 4.3-1733~g7d3aa11~xenial and am hoping that a related bug will have fixed this problem.