Nope setting bypass_all doesnt fix it.
Was this truly fixed in late May, or did you just not watch a lot of TV?
Sam
I did plenty of testing after the may release with the playerdebug info on screen and wasnt seeing any skips.
I upgraded to june and didnt really test to the same extent. Then upgraded to july and noticed the problem. I rolled back to june and still saw skips.
So looks like the issue maybe returned in june.
Very hard to tell because of the intermittent nature of the issue.
Ok,
Will take another look
Sam
The frame skips aren’t always that obvious to the naked eye, but if i show the playerdebug info on screen i can see the skip count gradually increasing when running the june or july releases.
I still had the .deb file from the may release:
vero3-mediacenter-osmc_18.2.0-13_armhf.deb
I installed this and the frame skips on live hd channels have gone.
So the issue of frame skips seems to have been (re)introduced somewhere between 18.2.0-13 => 18.3.0-11
If you have the deb files for versions in-between somewhere i can download then i’d be happy to do further tests if it would help pinpoint the issue.
I’ll see what’s changed from this version to cause the issue. I’m also suspecting that an issue may have been introduced by updating the Kodi version; which in turn seems to be using a newer version of ffmpeg.
Can you quickly get me the ffmpeg version from 18.2.0-13?
Sam
Looking in kodi.log on startup…
2019-08-18 20:37:25.953 T:4070658048 NOTICE: FFmpeg version/source: 4.0.3-Kodi
Thanks
Sam
If it helps… i performed a git bisect between 2019.05-2…2016.06-1 which tells me that the following commit reintroduced the frame skips in hd livetv:
Indeed, if i apply this single commit alone ontop of the may release (2019.05-2), then i get frame skips. Without it, i get 0 skips.
I’ll look in to this.
1 Like
I’ve been doing more testing over the past week, and the following combination seems to work ok:
- mediacenter-osmc package from july release
- kernel from june release (3.14.29-150-osmc)
- bypass_all=1 in rc.local
(only works on june kernel, since with july kernel interlaced content shakes up and down when bypass_all is set)
Hi @jahutchi,
bypass_all seems to be the way to go; but you do indeed get the shaking.
The problem must be in the kernel and come after 1ed49074c28625261a5867d70b816d964aca50b7
Although perhaps not – as I can reproduce this with the 150 kernel.
I can perform a bisect to track the troublesome commit.
I’ve grabbed the kernel sources from github and taken .config from the latest config file in /boot.
However, whatever make targets i try (deb-pkg, all, etc), i get the following errors:
gcc: error: unrecognized command line option '-mstrict-align'; did you mean '-Wstrict-aliasing'? KBUILD_CFLAGS_MODULE:-DMODULE CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CC kernel/bounds.s gcc: error: unrecognized command line option '-mstrict-align'; did you mean '-Wstrict-aliasing'? gcc: error: unrecognized command line option '-mgeneral-regs-only' /home/osmc/vero3-linux/./Kbuild:35: recipe for target 'kernel/bounds.s' fai led make[1]: *** [kernel/bounds.s] Error 1 Makefile:900: recipe for target 'prepare0' failed make: *** [prepare0] Error 2
Do you have any distro-specific instructions for kernel compilation? I searched around the forums/wiki but couldnt find anything.
Build it natively, if you can.
make vero364 on Vero 4K / 4K +
I can provide some tips on rapidly iterating over changes without going through the whole thing if it helps.
Comment out make-kpkg commands for headers and sources in build.sh in the interim. You don’t need them.
Thanks for the hints.
I’ve performed a git bisect and this has identified the following commit as causing the shaking picture for interlaced content when bypass_all is set:
i.e. the commit you suspected originally.
Indeed, the commit immediately before this one (dd00a2f) does not have the problem.
I reverted this yesterday. Thanks for confirming.
Ahh ok… looks like that hasn’t been pushed to the public github yet so hadn’t noticed you’d done that.
In terms of setting bypass_all in rc.local…
Is vero3-066-fix-deinterlacing-of-progressive.patch going to be (re)adjusted in the next release now that the kernel is fixed.
I’m currently running with a custom build of the mediacenter-osmc package; which includes a kodi bump, and the may/june version of the vero3-066 patch (containing the relevant lines to set bypass_all=1 for anything other than VC-1 content). This is working nicely.
Not sure yet — need to check. I know this caused some problems for others. You seem to be the only one affected by this problem, and you have a solution, albeit via command line.
Does your problem only occur for HD live tv?