Kodi Community Forum

Full Version: Live TV Viewing and Recording/Playback Sync Issues
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi,

I've already tried over in the tvheadend forum but nobody has taken me up yet. I suspect this relates more to the Kodi end anyway so this is likely the best place...

I'm just about there with my Kodi/Tvheadend setup on the Rpi2.
The only issue now is the sync between audio and video. I'm in the UK and this affects SD and HD channels, both live tv and their recordings.

With live tv it doesn't happen every time, but most of the time. I will start a channel and the audio will continue without problem, but the video will appear to surge/fast-forward for a moment early on, taking it out of sync.

With recordings they may be fine, but if I jump forward that will often break the sync too.
Viewing the recordings on a laptop running VLC under Mint Linux works fine, skipping forward no problem, although after watching a few different files it seems to hang (may be a completely unrelated issue).
I've since tried the HTSP plugin for VLC on the same laptop and had perfect results from my tvheadend server, over wifi, even in HD.

I have tried repackaging the SD recordings from a .ts to a .mp4 using ffmpeg and that seems to "fix" them.
I cannot do this with the HD recordings as it gives an error:
http://pastebin.com/raw/fiQbhn9m

I've tried running ffprobe on the recordings.
SD:
http://pastebin.com/raw/yuMUR21G

HD:
http://pastebin.com/raw/tR5YvL0j

I think I've tried all the different Kodi/PVR settings but I may be missing something.
Tvheadend itself is using the default protocol settings of HTSP -> LiveTV and Pass -> Recording.

Originally I was recording to the microSD card and HD recordings were terrible and corrupted, SD ok, even if I transferred them to another device for viewing. I'm now recording to a NAS which has fixed that. Bandwidth doesn't seem a problem having successfully recorded 3 simultaneous HD channels from one tuner/multiplex and 2 HD channels from different tuners.

Any other glitches in live tv, particularly HD were cleaned up my using a powered booster/splitter for my coax. According to my freeview box the signal quality was always 100%, but the booster took the strength up from 22% to 50%.

My setup:
RPi2 with mpeg2 codec license.
Sandisk 8GB class 10 microSD (verified with F3)
Arch Arm Linux
tvheadend 4.0.8-9~gce82e79 (compiled from AUR)
kodi-rbp 15.2 (from repo)
kodi-addon-pvr-hts (compiled from AUR)
Augustint T210 DVB (on a powered hub)
PCTV 290e (on a powered hub)

Can anyone please help me jump this final hurdle?
Can you post a debug log from Kodi?
Hi,

For each session I've started Kodi, opened a live TV channel for a short time and then exited Kodi. You'll note the tradition black screen on exit bug at the end of each one...

BBC One South - SD - no problems this time.

ITV - SD - sync error within moments of starting.


I'll try and produce the same logs when playing back the recordings too.

I appreciate you taking a look.
Hi,

He's another sync error from a live HD channel. I haven't managed to get a HD channel to play without error tonight, so no example yet.

BBC One HD - sync error
While I wait on feedback I thought I'd give the current version of OpenElec a go.
I recreated my setting and setup. It works.
Everything works.
Live TV. SD. HD. Playback of the recordings (old ones from the previous setup, so we know it's all about the playback).

As a Blender user I used to use Elephants Dream and Big Buck Bunny as test files.
On Raspian using Kodi 15.1 and 15.2, and on Arch Arm using Kodi 15.2 and 15.3 I found ED would not play at all. BBB would stutter during the first 10 seconds. Both A-OK now.

So this is great news in that we know the hardware and the software CAN deliver.
So what's the difference between running on OE and Arch?
I use my box for more than Kodi, so a locked down system isn't the place for me.

Cheers.
It might be a driver/kernel issue. Debian tends to be more conservative in updating to the latest kernels. Arch is a rolling release, and therefore considered nearly bleeding edge; OE is purpose-built, and therefore specifically optimized for Kodi.
Yes that's why I made the effort to test Openelec as it's meant to be comparatively "works out of the box". If that didn't work I suspected nothing would! Raspbian I thought would be halfway safe but no dice. I've been tinkering with this issue for over 6 months now but at least this is progress.

If it's likely to be an issue beyond the package itself then I think I'll approach the ArchArm community. Odd it's not been reported before. I can't imagine I'm the only user running kodi-rbp (so dedicated for Rpi use) from the ArchArm repository and using the PVR functionality. But perhaps I really do represent an "edge case"?
What are the relevant versions of the software stack? That will probably help in figuring out the issue. Which kernel, X version, which video driver, Mesa version. Those are just the primary pieces to consider, but others might be relevant too. (IIRC, Arch is running 4.4, while Debian is 3.18 I believe, I don't think they've moved to a 4-series kernel yet. The graphics drivers in use, too, will probably play quite a role in things, too. Arch is pretty current with Mesa 11.2; I doubt Debian is running later than 11.0)
Running uname -r on Openelec 6.0.1 I'm getting 4.1.16
Not sure how I can extract the rest! The release news from their site reports:
ffmpeg 2.6, mesa 10.6, Xorg-1.17, libva 1.6, systemd v219, binutils 2.25, Glibc 2.22, libressl 2.1.7, LLVM-3.6 and Kernel 4.1

I'll need to reimage my microSD card back to my ArchArm setup to check the corresponding stats. Will report back when I have those.
Thanks.
If you installed Kodi from a package on Arch it could be that it's compiled in a non-standard way (e.g. not bundling ffmpeg like the official build does). You could try building your own and see if the issue still remains.
That's an interesting thought. I've located the PKGBUILD for kodi-rpb . The depends and makedepends do not include ffmpeg (assuming that's what you mean by being built against ffmpeg). The make config doesn't reference anything with ffmpeg in it either.
I do have ffmpeg installed on my system .
I'd have imagined that I wouldn't get video at all without ffmpeg being present correctly, but perhaps I've misunderstood its role.

Omxplayer also isn't a dependency, but it is enabled in the make config. Its PKGBUILD does require ffmpeg I see.

So, is something wrong with that and if so what should be done?
In the meantime I shall attempt to build it on my system to see if that produces a different result as suggested.
Yes, that means it builds against your local ffmpeg installation which is an 100% unsupported scenario and has been and endless source of impossible to debug playback issues before. I suggest you build Kodi from scratch.
I successfully compiled the kodi-rbp package as provided, in case the provider had done something other than described. Same result.
I then tried to find what tinkering I could do and now I wonder how much of a red flag the PKGBUILD is.

If ffmpeg and omxplayer are built by code within the Kodi source, so I suppose they wouldn't need to be listed as dependencies.

With respect to the lack of mention in the configure flags I ran ./configure --help and there is an ffmpeg option.
Quote: --with-ffmpeg
ffmpeg options: auto (search pkg-config or auto build), force (always build ffmpeg), shared (link dynamically), path_to_ffmpeg [default=force]
But that reads like 'shared' would be building against my local ffmpeg installation and 'forced' would be the bundling we are after. As the default in its absence was forced then we should be good.
The other option, but they are already using it, is
Quote:--enable-player=omxplayer
which allegedly is the player of choice on the rpi.

Not sure where we go from here.
Just noticed the source.
It's from the xbmc git, but rather than using branch=15.2 to checkout the appropriate source branch it's using
Quote:source=("https://github.com/xbmc/xbmc/archive/$pkgver-$_codename.tar.gz"

Might that archive approach yield different results in terms of source used?

EDIT: Nope. Didn't work. I guess they have their reasons for doing it that way.
Tried uninstalling my omxplayer-git and ffmpeg packages and it did not break Kodi. So it's not relying on anything local, reinforcing the idea it was built with it's internal code.