Screen tearing on 1920 x 1080 @ 23.98 output

EDIT: Leaving the full post below so my thought process can be traced, in case I took a wrong turn somewhere, but the issue appears to be screen tearing on the OSMC output when set to 1920 x 1080 @ 23.976 Hz (reported in the system as 23.98, possibly related to the problem?).

Original Post:
I’ve been experiencing a very peculiar issue with the video output of OSMC from my Vero 4K+ since the January update (or possibly the prior update; I don’t have a perfect recollection of when it began): The top 2-4 lines of pixels appear to be lagging behind the rest of the video (per my edit below, this is likely just a form of screen tearing that I didn’t recognize as such at first glance).

Sometime in the past couple months, I began seeing odd glitches at the top of the screen that were noticeable when a video shifted from a light scene to a dark scene or vice versa, but at the time, I just chalked it up to some sort of encoding error with source files and didn’t think much of it. As time went on, however, I noticed that it was happening on all of my source files, which prompted me to take a closer look. When I got up close to the television, I discovered that the top couple lines of pixels seemed to be showing picture that was slightly behind the rest of the video. It’s hard to describe, so I’m linking a quick video I took with my phone to try to demonstrate it: OSMC Screen Tearing. I apologize for the quality; I essentially never take videos on my phone and just used the default settings to put something together quickly.

Here are some snapshots of the issue from that video for quick reference, as well, although it’s harder to grasp without seeing it in motion:
Light to Dark Transition
Dark to Light Transition

Some additional notes about the behavior that I observed: The issue appears to be covering about a line and a quarter of the 1080p output, which impacts 2 lines plus a quarter of the next 2 lines of pixels on the 2160p screen. Also, if you pause the video, the aberrant pixels “catch up” before settling into the pause. EDIT: This obviously makes more sense now that I’m thinking about it in the context of screen tearing, since the output buffer is just a static image when paused, so the tearing will be invisible after one frame passes.

I’ve never seen anything like this before with OSMC, so I wasn’t entirely sure where to begin with troubleshooting. I verified that the source files weren’t the issue by playing them back on my computer and other devices, on which they performed normally. I checked the logs to ensure that OSMC was engaging the proper playback mode for the source files, all of which are standard 1080p / 23.976 / 4:2:0 / 8-bit MKVs, and it appeared to be doing so. I checked the video calibration settings for 1080p / 23.976 within Kodi to confirm that no overscan or pixel ratio settings had gotten bumped around, and they were all at their defaults.

My next assumption was that something odd was happening further down in the signal chain, but I tried playing the files via Kodi on my Shield TV with the settings matched as closely as possible to OSMC and with both outputting the native signal (i.e., switching res/framerate to 1080p/23.976 to match the source), hooked up through the exact same signal chain of AVR (Marantz NR1606) and TV (LG B6), and the issue wasn’t present under those circumstances either. As such, the issue seems to be tied solely to the output of OSMC from the Vero 4K+.

I’m rather stumped at this point, so I wanted to reach out here for support. This is a log of playback with debug and video component logging enabled: OSMC Paste. It’s edited to redact some file paths and remove the previous log portion (since the single session log was already gigantic with video component logging), but is otherwise untouched.

Has anyone else experienced a similar issue after the recent updates and determined a solution? Is there some setting that I’m missing that could be driving this issue?

EDIT: On a hunch, I switched the OSMC GUI from 1920 x 1080 @ 59.94 to 1920 x 1080 @ 23.98, and the issue is now visible in the interface itself, so the problem apparently has nothing to do with video playback at all, but is rather related to how OSMC is displaying frames on the 1080p @ 23.98 setting. I’m now wondering if what I’m seeing is some form of screen tearing, which fits the particulars of the issue cleanly, but didn’t occur to me as a possibility in this technical context. I’m familiar with the causes of tearing on PC applications that have variable framerates, but have no clue how vertical syncing works on home video devices where framerate is expected to be constant, and I’ve never run into screen-tearing with film playback before.

For kicks, I tried switching the output to 1080p @ 24.00 and the issue disappeared. Are there any further tests I could run to help track the issue down on the 23.98 setting?

Weird, I’m seeing this ‘sometimes’ as well… what’s really weird is if you use an FPS test video (horizontally scrolling bars, like this one ), and vertically shift it up to the top it doesn’t seem to repro? As soon as I switch the gui to 23Hz, the confirmation dialog does indeed tear for me right away (after the display switches to that frequency).
I also tried a full aspect 23.976fps video (HDTV source) and it didn’t seem to suffer, but that was more difficult to tell.
I have seen some similar weirdness on the bottom edge of 1080P23/HDR videos, though (but again, only sometimes). Could this all just be encodings/video pipelines that the graphics chip just doesn’t quite like?

Interesting… It sounds like when you set the GUI to 23.98 Hz, you’re seeing tearing in the middle of the screen? Does it always tear in the same place when you set the GUI to 23.98 Hz, or is it random where the tearing occurs each time you select that output framerate?

Correct, middle of the screen the first time, but I struggled to see any more after that… granted I didn’t look very thoroughly, just a few different screens.

Most curious. @sam_nazarko Is there any sort of v-sync / “vertical blank sync” setting that we can manipulate in OSMC via config files, similar to the settings available for Kodi on Windows/Android/other platforms?

Do you have any kind of motion smoothing feature turned on for your TV? These go by various names (TruMotion, Auto Motion Plus, MotionFlow, etc.) but whatever it is called they can sometimes add funkyness to certain signals that are not intended.

If you enable Adjust Refresh Rate, set the GUI to say 50/60Hz, do you experience a problem?

All motion smoothing controls are fully disabled, and “Real Cinema” mode (which is LG’s setting for leaving 23.976 Hz / 24 Hz signals untouched) is enabled. As mentioned, the same 23.976 source files operate smoothly (no tearing) from all other sources, including Kodi running on another device, so the television seems to be happy enough handling the signal in general.

Yes. My standard configuration for OSMC has always been GUI at 1920 x 1080 @ 59.94 Hz and Adjust Refresh Rate on for media, and the issue definitely occurs during playback of 23.976 Hz media under those circumstances. I only tried swapping the GUI to 23.98 later to see if the GUI itself would tear, which it did.

After more testing, I could not reproduce the (obvious) tearing on mode switch in the gui. I also navigated around, played with the sliding menu on the side coming in&out, and no sign of it. Leads me to be believe maybe a timing problem/drifting clock? I also have an LG (65B7A, to be specific) and I wouldn’t put it past LG to have F’d something up in the TV (or the vero is sending a signal that may not completely jive with the edid ‘sometimes’ ?)…
Anyway, I’m not going to worry about it until after the big 4.9 kernel update, then I can do more testing.