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?