July Update TVHeadend problems

Hi,
since the update to tvheadend 4.2, my live TV in OSMC is a little stuttering. When i fall back with my backup to OSMC 17-3 march patch, everything is smooth with 4.0.9.

So my question is:
Is there a way, to update just OSMC (July patch) without updating the tvheadend to 4.2?

Tvheadend is installed from the OSMC store.

Thanks for your help in advanced! And sorry for my english…

If you are comfortable reverting, you can then use this command:

sudo apt-mark hold armv7-tvheadend-app-osmc

Which will prevent it from upgrading to 4.2

EDIT: Forgot to say that it would be better to find what the issue is so that @sam_nazarko can fix it for everyone’s sake. Could you post logs and maybe make a screenshot of the info panel (that you can bring up pressing the dotted list on the official remote) when the stutter occurs?

Hi,
and thanks for your help! I will try it in the next couple of days.

Wich kind of log file you want? The normal Kodi.log? You mean the info panel with the CPU usage?

BTW… I’m not the experienced user, but i will do my best :wink:

So, just did the update with “apt-mark hold” and everything went fine.
OSMC is July patched and TVHeadend is on 4.0.9.

…but, I have stuttering Live TV. Seems like the patch is my issue, not tvheadend.

Any Ideas?

Kodi.log

In the log you can see channel switches between German commercial TV channels in Full HD (1920x1080) resolution and often warnings

CRenderManager::WaitForBuffer - timeout waiting for buffer

I think at least you need to provide more details how the video stream gets into the OSMC box, so what tuner is used, how is it connected etc.

Have you checked the OSMC’s July Update thread for obvious changes affecting you?

Hi JimKnopf,
The rpi 3 is client and server at once. The USB DVB C stick (Silicon Labs Si2168 name in tvheadend) and a easymouse for decrypting HD channels (OSCam) are connected over an aktiv USB hub to the pi.
Didn’t changed anything on the hardware side.

Should I make a kodi log of the “old” system to compare? (March and 4.0.9)

Patch notes don’t affect me at this point.

I’m just an interested reader here but that sounds like a good idea providing in a single post two debugging logs with

a) OSMC 2017-03 + tvheadend 4.0
b) OSMC 2017-07 + tvheadend 4.0,

so the gurus here have an easier access for things to compare.

Could you also try the channel “ServusTV HD” since this is FULL HD (1080i) and public?
With that you can from logic simply eliminate all this decrypting stack as reason.

So, here the log files.
I did them all the same way. Fresh start, enable debugging, switched to Live TV “Servus TV HD 1080p”, runtime about 3min., copied the file.
“Servus TV” is unfortunaly not a public (free) channel in Kabel D, so decrypting was on (The OsCam log is normal, no failures/errors at all).
Anyway, on “ZDF HD 720p” i’ve got the same issue and thats a free/public channel.

Log files of:

OSMC 2017-03 + TVH 4.0.9 click
OSMC 2017-07 + TVH 4.0.9 click
OSMC 2017-07 + TVH 4.2 click

I hope, i did it right and someone can get something out of it…
Thanks in advanced!

So, nobody else has an idea?

At least it looks to me from the logs that hardware acceleration by OMXplayer is active.

The user @popcornmix advises in this current thread to NOT use this feature on Pis 2 and above.

On my Pi 2 model B unter Settings -> Player -> Videos -> processing the HW acc OMXplayer is deactivated and HW acc. MMAL active.

No idea whether this is really related to your issue.

My pi is running on the same settings like yours, so OMXplayer acceleration is deaktivated.

Thanks for your efforts!
Seems like nobody else have this issue…

I have the same problem after upgrading. Occasional stuttering and some crashes. I will provide logs as soon as I can

Here’s my Kodi.log, created just after I found out that the Server crashed completely.

Not sure where I can find TVHeadend’s Log

Edit: Here’s one with “Syste Journal” enabled. Looks like the process get’s killed?

Aug 15 20:23:00 osmc2 kernel: Out of memory: Kill process 10894 (tvheadend) score 655 or sacrifice child
Aug 15 20:23:00 osmc2 kernel: Killed process 10894 (tvheadend) total-vm:735728kB, anon-rss:490616kB, file-rss:0kB, shmem-rss:0kB
Aug 15 20:23:00 osmc2 systemd[1]: tvheadend.service: main process exited, code=killed, status=9/KILL
Aug 15 20:23:00 osmc2 systemd[1]: Unit tvheadend.service entered failed state.
Aug 15 20:23:06 osmc2 systemd[1]: tvheadend.service holdoff time over, scheduling restart.
Aug 15 20:23:06 osmc2 systemd[1]: Stopping TVHeadend Server…
Aug 15 20:23:06 osmc2 systemd[1]: Starting TVHeadend Server…
Aug 15 20:23:16 osmc2 tvheadend[16475]: main: Log started
Aug 15 20:23:16 osmc2 tvheadend[16475]: tcp: No systemd socket: creating a new one
Aug 15 20:23:16 osmc2 tvheadend[16475]: http: Starting HTTP server 0.0.0.0:9981
Aug 15 20:23:16 osmc2 tvheadend[16475]: tcp: No systemd socket: creating a new one
Aug 15 20:23:16 osmc2 tvheadend[16475]: htsp: Starting HTSP server 0.0.0.0:9982
Aug 15 20:23:16 osmc2 systemd[1]: Started TVHeadend Server.

I’ve got problems after july update with DVBlink: Vero 4K and DVBlink channel loading slow - #26 by teetniin
It seems to me there is problem with livetv and hw acceleration.
I’m using Vero 4K, but maybe there is some general problem with HW acceleration and some type of livetv streams.

I don’t think this is specifically a tvh problem, unless you upgraded only tvh and nothing else. You seem to have trouble mounting nfs shares

Aug 15 21:26:28 osmc2 kernel: nfs: server 192.168.178.4 not responding, timed out

which may or may not be relevant, but the other thing I notice is the lines just above the Kill process:

Aug 16 20:14:57 osmc2 kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Aug 16 20:14:57 osmc2 kernel: [ 3602]  1000  3602   190922    42468     213       0        0             0 kodi.bin
Aug 16 20:14:57 osmc2 kernel: [16475]  1000 16475   191680   126457     286       0        0             0 tvheadend
Aug 16 20:14:57 osmc2 kernel: Out of memory: Kill process 16475 (tvheadend) score 676 or sacrifice child

If total_vm means what I think it means, you have run out of memory very early. Running top on my Pi says this:

top - 10:22:44 up 2 days,  1:16,  1 user,  load average: 0.92, 0.88, 0.76
Tasks: 172 total,   1 running, 170 sleeping,   0 stopped,   1 zombie
%Cpu(s):  4.7 us,  3.9 sy,  0.2 ni, 87.9 id,  2.3 wa,  0.0 hi,  1.0 si,  0.0 st
KiB Mem:    749588 total,   722256 used,    27332 free,    11628 buffers
KiB Swap:        0 total,        0 used,        0 free.   403048 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
24974 osmc      20   0  724852 167088  39476 S  19.7 22.3 113:25.47 kodi.bin
24953 osmc      20   0  325792  19780   3208 S  15.1  2.6  10:58.55 tvheadend
  499 pulse      9 -11  100108   3272   1984 S   0.0  0.4   0:00.33 pulseaudio

I assume you ought to have 1G memory, perhaps you have got a hw problem.

Thank you very much for your support. Unfortunatly I don’t understand the “total_vm” thing. Does this mean there is a problem with my RAM? Can I provide some more infos that would help you?

I also noticed the NFS timeouts in the logs, it’s the share for the DVR. But I did not notice any problems accessing the share, and the planned records all seem to be ok

What do you see when you go to Settings - System info - Hardware?

Nothing wrong there, apparently. From a bit of Googling, I see total_vm in that message is measured in 4k blocks so I was barking up the wrong tree, sorry.

I can only suggest systematic enabling/disabling of bits of your system (you have quite a bit of hardware, there), plug-ins, etc, to home in on what’s causing the problem.

If you have stuttering video with OSMC releases later than April, you could open the Tvheadend webinterface in a browser and check the „Continuity Errors“ column on the „Status“ page. If the counter increases permanently, then welcome to the club.