No I’ve also seen problems with SD channels, and also SD & HD recordings.
The other day I had bypass_all=0 set when watching an SD channel (Film4), and the picture was miles behind; running in slow motion (audio was OK). I did a little channel surfing and saw the same on other channels. Then I returned to Film4 which still had the same problem.
I went in the command line and set bypass_all=1 and immediately it was like someone had shoved a rocket up it… playback went back to normal speed and everything was nice and smooth again.
I’ll check and work out the best way to solve.
Maybe there needs to be an option - e.g. enable post-processing
It is unusual that i’m the only one affected. I’m running latest tvheadend stable 4.2.8 on a debian server (8th gen intel nuc). I splashed out on this a couple of months ago wondering if my previous 9 yr old server (revo 3700) was outdated and underpowered, and maybe this was causing some kind of lag. But it didnt change anything.
I shall seperately do more investigations on the tvheadend side of things. I’ve not really looked at that side of things yet, as other pvr.hts clients are fine (rpi3, android phone, old revo3 machine - vdpau), so I have naturally blamed the vero. However there is clearly something about my streams that the vero (in particularly the di module) struggles with.
Just to let you know, i did more investigations earlier into that commit and after a couple of extra kernel builds i managed to figure out that it was the adjustment to the VPP_PHASECTL_INIRCVNUM_WID define that caused the shaking - if i reverted that single line change (rather than whole commit) the shaking went away.
Guess it doesnt matter if you’ve reverted the whole commit, but thought it was worth sharing.
Cheers - the changes were to match the data sheet; but we don’t trust the data sheet
Latest on this was that I upgraded to kodi 18.4 and bumped the version of ffmpeg used by tvheadend from 3.4.5->3.4.6.
I’m now running happily without bypass_all set have been for a good few days now.
Only remaining problem is that occassionally when watching livetv i get constant single frame skips. If I stop/start the same channel it often goes back to normal.
Here is a debug log: https://paste.osmc.tv/cumaluqewo
If i watch the logfile when its skipping frames i can see these messages written each time it skips a frame
2019-09-19 20:20:52.708 T:3361850080 INFO: CVideoPlayerVideo - Stillframe detected, switching to forced 50.000000 fps
2019-09-19 20:20:52.708 T:3361850080 INFO: CVideoPlayerVideo - Stillframe left, switching to normal playback
Glad there are some improvements now.
Do you have a file that can reproduce this problem?
Sam
Nope - so far i’ve only seen it happen in livetv. Next time it happens I’ll hit record and see whether the resulting file has the same frame skips. It’s important to note there were no errors in the tvheadend logfile when this was happening.
<setting id="videoplayer.usedisplayasclock">true</setting>
...
id="videoscreen.whitelist">0192001080023.97602pstd,0192001080024.00000pstd,0192001080029.97003pstd,0192001080050.00000pstd,0192001080059.94006pstd,0192001080060.00000pstd,0384002160023.97602pstd,0384002160024.00000pstd,0384002160029.97003pstd,0384002160050.00000pstd,0384002160050.00000pstd,0384002160059.94006pstd,0384002160059.94006pstd,0384002160060.00000pstd,0384002160060.00000pstd</setting>
Might be not not relevant for your issue but GUI->settings->player->videos->Sync Player to Display is active which also prevents audio passthrough. Don’t do that.
Also try to activate all or none offered entries at GUI->settings->system->display->whitelist. It looks like you have explicitely deactivated the 25Hz modes although your display tells to be capable of this.
Schoolboy error 
I had been experimenting a couple of weeks ago with various settings in trying to fix this, but I do know better than to leave this setting enabled for every day use.
I’ll grab fresh logs and take a recording of the program the next time I come across the issue, in the hope that the recorded .ts file also demonstrates the problem.
I can also pop into another room to play the same live stream from my rpi3 to see if that’s equally affected at the same time (it’s connected to the same TVH server).
I had some frame skipping on a livetv channel so hit record and the same skips didnt occur when I played back the recording.
I do however have one recording from a few days ago which completely chokes when played back with bypass_all=0, it basically plays in slowmotion…But plays back perfect with bypass_all=1. Seems different symptoms to the occassional frame skipping in livetv but can upload a sample if you’re interested?
I’m now going back to the workaround of setting bypass_all=1 in rc.local…
Were you watching BBC One?
Nope, it was CBeeBies HD on this occassion
Unfortunately still seeing frame skips in livetv with bypass_all=1 set.
Again this was on CBeeBies HD
Debug log has been uploaded here: https://paste.osmc.tv/divefuyita
And still the case that recordings aren’t affected?
Sam
Correct, I haven’t yet seen the frame skips when watching recordings.
Ok – I’ll see if I can reproduce
If you record as MKV, the issue should be reproducible