Anyone with tvheadend issues?

So i have shifted from OSMC on my Raspberry Pi 2 to the new Vero 2. Until now only tvheadend and smb from the app store as well as my usb dvb-s tuner (Sundtek SkyTV Ultimate) have been installed to the Vero 2.

I have setup Live TV through tvheadend the same as on my raspberry pi 2, but on the Vero 2 i am experiencing some problems: On the rpi2, the tv image runs smoothly, on the Vero 2 i keeps halting/stuttering after different time spans around 30 seconds. If this were youtube, i would guess that it is buffering. Is anyone else experiencing something like this or has some tip for me how to figure out the origin of the problem? Currently, Live TV is not usable for us on Vero 2 and we keep falling back to the Raspberry 2 until we find a solution.

Thank you very much.

Ok so nobody else is experiencing issues like that.
Maybe somebody has a recommendation for me about how to start resolving the issue? What would you look into first?

I will investigate this for you

To get a better understanding of the problem you are experiencing we need more information from you. Please see How to submit a useful support request - General - OSMC for advice on how to help us.


Hello Sam,

Thank you for your help:

The issue you are currently experiencing with OSMC

  • Moving from RP2 to Vero 2, Live TV (Sundtek SkyTV Ultimate) is not usable, since after a few seconds, video hangs.

What you were doing when this issue occurred
Just having a chosen tv channel open

Whether you can replicate this issue on demand. If you can, then please provide some steps on how an OSMC developer can reproduce the same issue.
The problem always occurs and with any tv channel

The device you are currently running OSMC on
Vero 2 with April update just installed, nothing installed yet but tvheadend, smb and tv tuner driver

What peripherals are attached to the device?
Sundtek SkyTV Ultimate, the provided OSMC Store bluetooth and remote dongle

Has this issue been introduced by a new version of OSMC? When did the issue first appear and can you recall a time when it was not present?
The issue has been there since Vero2 has arrived

Here are the uploaded logs

Thank you very much, I hope to finally get the vero 2 up an running with your help!

Hi cpeters,
I am running tvheadend on a separate PC and I can switch between different signal sources: SAT-IP, IPTV via a SAT-IP receiver and IPTV via DSL (multicast).
Prior to the April update of Vero 2, I had occasionally re-buffering issues when watching HD-TV programms. After installing the April update, it became much worse: Audio and video gets out of sync and rebuffering occurres regularly.
As a work-around I switched to a SD-signal source which still has rebuffering every few minutes (but at least audio and video remains in-sync).

I double checked with a Kodi installation under Ubuntu - all channels display smoothly. Hence something in the latest Vero update must have broken the connection between the tvheadend HTSP client and tvheadend. It only affects Live-TV, recordings are shown without problems - hence I exclude tvheadend and the signal sources as origin of the problem.
The HTSP client is still at version 2.2.14 (the same version that runs under Ubuntu perfectly).
I am still investigating the issue.


Hi guys,

I’ll follow up on this shortly.


1 Like

Something must have changed regaring the MPEG4-Decoding. Previously, when a live stream had a continuity error (i.e. a dropped frame) there was just a short interruption, shortly afterwards audio and video were back in sync. Now, Vero 2 (with HTS backend) seems to stumble over the first continuity error in a MP4 stream.
What is odd, when recording such a stream (via tvheadend), the stream still has continutiy errors, but playback works.

Unfortunately, TVHeadend doesn’t always package videos correctly, and there have been some workarounds to fix some playback issues. This seems to recur across a lot of TVHeadend versions, and even exists in some recordings as well.

I’d be interested in knowing if disabling Hardware accelerated decoding (via Playback) in Settings helps at all.

Diabling hardware acceleration results in massive frame drops - so unfortunately, this is not an option für MP4 live streams. With hardware acceleration enabled, I notice roughtly 200 dropped frames within 10 seconds - so the video lags serveral seconds behind audio (tested with versions 16.0.0-12 and 16.0.0-14).

Any change to revert to a previous version (without reinstalling)?
I had a look at: Index of /osmc/osmc/apt/pool/main/v/vero2-mediacenter-osmc, but could find only the most recent versions.

Right now the work-around is to watch only SD channels which still work well (with and without hardware acceleration enabled).

I guess I found the issue here:

A patch was already applied to the pvr.hts plugin (master branch). Any chance to get this quickly into OSMC?

1 Like

Good find – if it can be backported, I’ll try and get it in the next OSMC update.

Quick question: Should the May Update solve this issue? Thanks for your support.


We didn’t update TVHeadend or the pvr.hts plugin in this update. I’ll see if we can backport the changes to Kodi, which is probably the solution. Ideally we want this done upstream.


Quick question again: Should the July Update solve this issue?

Thanks again for your support but it is really too bad my Vero 2 has been useless to me for half a year now. Without proper live tv and the android image (correct me if this has been released in-between?), this is just an expensive brick in my closet.

We have not made changes in this release to TVHeadend or LiveTV.

Can you confirm if recording the clip and playing it back exhibits the same problem?
If so, can you upload a small recording which exhibits the problem to Dropbox


I can confirm that the issue also exists during playback:

Thanks for the sample. I’ll take a look


I took a look at this sample. With the latest OSMC (and some changes staged for August 2016 update), the audio and video are in sync and the video plays back OK. There is about half a second of artefacting which appears to be due to a problem in the recording itself.

Can you describe the problem you are experiencing?