Hi @twarkie
I see this early in the logs:
Jul 29 21:43:06 osmc kernel: DI: di_receiver_event_fun: vframe provider reg
Jul 29 21:43:06 osmc kernel: tv_vout: vout [tv_set_vframe_rate_hint] duration = 4004, policy = 1!
Jul 29 21:43:06 osmc kernel: tv_vout: vout [framerate_automation_process] duration = 4004
Jul 29 21:43:06 osmc kernel: tv_vout: framerate_automation_process[1111] fps_playing_flag = 1
Jul 29 21:43:06 osmc kernel: tv_vout: fr_vsource = 2397
Jul 29 21:43:06 osmc kernel: tv_vout: mode_target=16,is_receiver_supported=1
Jul 29 21:43:06 osmc kernel: tv_vout: vout [framerate_automation_set_mode] mode_target = 16
which indicates that framerate automation is enabled; but I don’t think I actually saw it active when you played your clip, which would explain the skipping.
I’ve noticed this on some newer TVs which don’t seem to advertise a preferred mode. I’d recommend trying these improvements here. They will likely end up in OSMC proper very shortly, so it’s worth trying anyway. After you boot, run sudo chown osmc:osmc /sys/class/amhdmitx/amhdmitx0/frac_rate_policy. This won’t be necessary in the next update (but for now the permissions for this sysfs node were incorrect).
This kernel allows fractional video modes, i.e. 23.976 to be set from userspace without the ‘magic’ that used to happen before. It will also make it much easier to see if framerate automation is working as expected. The value of sudo chown osmc:osmc /sys/class/amhdmitx/amhdmitx0/frac_rate_policy should be 1 when you are playing back content with Adjust Refresh Rate enabled; otherwise 0.
Another thing worth testing, is whether Sync Playback to Display removes the issue. I know that this will prevent passthrough and I am only suggesting it as a quick test. If it does remove the issue, then it’s indeed a problem with the Adjust Refresh Rate option
Fortunately, you seem familiar with the command line and how to troubleshoot things, so I think we should be able to resolve this one quite quickly for you.
Sam