Tvheadend

I can stream/watch 4 SD unencrypted streams at the same time, each from a different muxes for an hour without a problem. Haven't tested for a longer time period.

When I start recording more than 1 stream, to a windows share (so not through USB), stream profile "pass", cache scheme "don't keep", both network traffic nor processor are a problem. But available memory goes down and when it's too low, the process is stopped, processor spikes.

After the above, I stopped watching the 4 streams, started recording 2 streams. Than stopped 1 of them, so I'm recording just 1 stream.
Resident memory still goes up, now abount 308MB, virtual memory about 725MB. TvHeadend gui becomes unresponsive, I can't reach it anymore. Have to stop the service after which memory goes up.

Restarted service tvheadend, which continues to record the 1 stream. Free memory goes down to about 25MB, available memory stays at about 733MB. Then 18 minutes after the start of the recording, maybe at that time I tried adding a recording after the one I'm recording at the moment, Kodi gives me a pvr error and I can't program a new show. Than free memory goes up and available memory goes down. These last both continue to go down. TVHeadend gui becomes unresponsive, I can't reach it anymore. Have to stop the service after which memory goes up.

14:40 Restarted service tvheadend, which now doesn't go further recording the old show. Started recording 1 new show. Available memory looks stable at 734MB, free memory going down starting at about 617MB. Now I'm not touching pi/tvheadend/kodi again.
14:41 free memory goes down again
14:46 free memory goes up, then down again and now available memory also goes down which is usually the sign of the start of a bad thing.
15:15 memory seems to be stabilizing at: available 518MB, free 379MB.
16:00 free memory stable at 25MB, available down to 80MB. TVHeadend gui becomes unresponsive, I can't reach it anymore. Have to stop the service after which memory goes up.

16:05 Now changing configuration to store recordings locally (in pi) instead of on windows share. Keeping stream profile "pass", cache scheme "don't keep". Recording 1 show.
16:24 Free memory went down immediately to a stable 26MB, available seems stable at 728 MB.
16:49 Stable.
17:22 Stable. Added a second recording (different mux). Free 666MB, available 759MB.
18:02 Stable.
18:11 Stable. Added a third recording (different mux). TVHeadend gui unresponsive, I can't reach it anymore.
When I type: sudo service tvheadend status -l, I get:
Loaded: loaded (/etc/init.d/tvheadend)
Active: active (exited) since zo 2017-02-19 16:02:13 CET; 2h 18min ago
Process: 26325 ExecStop=/etc/init.d/tvheadend stop (code=exited, status=0/SUCCESS)
Process: 26408 ExecStart=/etc/init.d/tvheadend start (code=exited, status=0/SUCCESS)

feb 19 18:00:53 raspberrypi tvheadend²⁶⁴¹⁹: mpegts: too much queued table input data (over 2MB), discarding new

Syslog:
Feb 19 18:00:10 raspberrypi tvheadend²⁶⁴¹⁹: mpegts: too much queued table input data (over 2MB), discarding new
Feb 19 18:00:13 raspberrypi tvheadend²⁶⁴¹⁹: mpegts: too much queued table input data (over 2MB), discarding new
Feb 19 18:00:13 raspberrypi tvheadend²⁶⁴¹⁹: mpegts: too much queued table input data (over 2MB), discarding new
Feb 19 18:00:13 raspberrypi tvheadend²⁶⁴¹⁹: mpegts: too much queued table input data (over 2MB), discarding new
Feb 19 18:00:14 raspberrypi kernel: [118212.710689] TCP: request_sock_TCP: Possible SYN flooding on port 9982. Sending cookies. Check SNMP counters.
Feb 19 18:00:16 raspberrypi tvheadend²⁶⁴¹⁹: htsp: 192.168.2.1 [ tvheadend | Kodi Media Center ]: Write error -- Gebroken pijp
Feb 19 18:00:20 raspberrypi tvheadend²⁶⁴¹⁹: mpegts: too much queued table input data (over 2MB), discarding new

Stopping tvheadend service.

I think I've got another problem here (broken pipe). Any help appreciated.

Wim

EDIT:

Checked rpimonitor again and saw that from 17.45 onwards, available memory has gone down.

Someone told me that since Jessie there's often a 'broken pipe' in the connection through ssh. This is supposed to be a consequence of the use of systemd. The mode in which sshd runs should be changed.

In your previous post you mentioned storing files on a network share. I'm not sure if you realized, but the network interface and the USB share a single bus. So, that's the network and all 4 USB ports sharing a single bus.

Robert Cameron wrote:

In your previous post you mentioned storing files on a network share. I'm not sure if you realized, but the network interface and the USB share a single bus. So, that's the network and all 4 USB ports sharing a single bus.

I did know that, but didn't know whether the usb itself could be a problem, besides the bus. And with rpimonitor I could check ethernet perfectly whereas I couldn't monitor the usb like this so well.

Could the broken pipe be the cause of the memory issue?
I think I've solved the broken pipe connection now and I'll be testing again with stream profile "pass" and cache scheme "don't keep" hoping I can now see what the bottleneck really is.

Any insights appreciated.

Wim

Well, I solved the broken pipe issue.

Then I saw "mpegts: too much queued table input data (over 2MB), discarding new" in syslog.
I read here on the forum that it's solved in a newer version:
https://tvheadend.org/boards/5/topics/22955?r=22956#message-22956
so I installed the latest version. Solved too.

Now, I keep having memory issues (I'm stretching the cord here to see where it breaks).
I have stream profile=pass, cache scheme=don't keep.
TVheadend consumes increasing amounts of memory, up to the point of tvheadend being killed:

Feb 23 20:11:48 raspberrypi kernel: [44640.723820] Out of memory: Kill process 1 9210 (tvh:dvr) score 747 or sacrifice child
Feb 23 20:11:48 raspberrypi kernel: [44640.723838] Killed process 19210 (tvh:dvr ) total-vm:1217084kB, anon-rss:734836kB, file-rss:0kB

As far as I can tell (htop, rpimonitor), neither CPU or network is a problem. Nothing in syslog too.
Sorry for asking a silly question, I'm a noob, but from this post below I thought tvheadend shouldn't consume increasing amounts of memory:

Adam Sutton wrote:

That only relates to if you want timeshift etc...

Generally TVH is pretty lightweight. The installation size (if you use --bundle) is about 5M (I think, from memory). My own configuration (DVB-S dual tuner with ~150 channels is about 40M, 12M of that is EPG data). It has no other temporary files, but will need a few 10M's min for memory.

If you want timeshift and/or recordings then you'll obviously need some disk space somewhere, but that could either be USB/network attached etc...

Adam

Wim

I'VE GOT IT!!!! At least that's what it looks like at the moment:
It's the over-the-air EIT DVB grabber.

Although it's configured standard:
Over-the-air Cron multi-line:
Default config (02:04 and 14:04 everyday)
4 2 * * *
4 14 * * *
EPG scan timeout in seconds (30-7200): 600

it just starts at various other times and when it does I get:

Feb 24 10:11:42 raspberrypi tvheadend⁶²¹: subscription: 0042: "epggrab" subscribing to mux "444MHz", weight: 4, adapter: "HDHomeRun DVB-C Tuner #0 (192.168.2.17)", network: "Ziggo", service: "Raw PID Subscription"
Feb 24 10:11:49 raspberrypi tvheadend⁶²¹: mpegts: 444MHz in Ziggo scan complete
Feb 24 10:11:49 raspberrypi tvheadend⁶²¹: mpegts: 412MHz in Ziggo scan complete
Feb 24 10:12:09 raspberrypi tvheadend⁶²¹: mpegts: too much queued table input data (over 2MB), discarding new
Feb 24 10:12:12 raspberrypi tvheadend⁶²¹: mpegts: too much queued table input data (over 2MB), discarding new

causing a shortage of memory, then tvheadend being stopped.

At the moment I am recording 4 HD ecncrypted channels on different muxes and RES is steady on 31MB.

Should I open a new thread for this?

Please help.

Wim

Update:

Broken pipe caused memory flooding. Fixed.

Bug in tvheadend. Fixed (in latest version).

EPG scan does NOT start at various times, I forgot that those times were after a reboot (and tvheadend is set to do a epg scan after startup). Fixed.

I had problems with certain channels that were not descrambled/decoded by oscam correct. Recording those channels causes memory flooding so I unchecked "Continue even if descrambling fails" in stream profile "pass". Fixed.

Continuity errors cause memory flooding. The past days I almost got none, today I get a lot of them, when recording 4 HD encrypted channels. No clue why today it's so bad.

While the past days tvheadend used 31MB for 4 HD encrypted channels, today I can record only 3 without memory flooding.
I think that CPU/bus are indeed the bottleneck. But, I think that for a pi, 3 encrypted HD muxes aren't bad.

Wim