LE12, RPi5, timing issue? skips ahead. very intermittent

  • Occasionally on RPi5 LE12 seems to get into this strange state where it's trying to skip ahead slightly. It starts with very small skips, that you might easily miss if you're not paying attention, just a frame here and there, but when it starts, it progressively gets worse, trying to skip further ahead as far as a second or more, until it's impossible to ignore, and eventually becomes unwatchable.

    It can do this on h.264 and h.265 (my understanding is only the latter uses hardware accel on RPi5, so it seems unlikely to be that causing or preventing it). Interlaced or progressive. From Plex via "PM4K for Plex" or via PlexKodiConnect; from NextPVR (running on another machine) whether playing recordings or live TV. Nearly all sources are 1080p with some 1080i and occasional 720p.

    (When it happens while watching live TV, the effect seems to be to initially catch up with any slight lag there might be from live, and then it's trying to skip into the future, at which point it looks like it's buffering - waiting for the time it's skipped to to actually arrive.)

    It seems unaffected by changing settings related to buffering or caching, and whether wired or on wifi... it's skipping *ahead* not falling behind.

    It's not a problem with the source media - the same media will play fine on another occasion or on another device.

    It's very intermittent. I can go weeks without it happening at all, and then it seems to happen frequently for a bit. It can happen soon after starting watching, or after hours of it. Sometimes rebooting the RPi5 seems to help, other times it doesn't. Sometimes just *waiting* a bit seems to help. This pattern often means I think it's been fixed, eg: when it didn't happen for weeks after LE12.0 actually came out (vs the betas) but that appears to have been a fluke.

    It *feels* like some kind of timing issue, as if the system clock is literally getting ahead of itself, and the player consequently trying to play video from whatever backend is serving it from just slightly ahead of where it should be. Which may make it a kernel issue. The skip-aheads are short, but enough to render it unwatchable, and as noted, it seems to start with very very short skips, gradually getting longer over a period of a minute or two. Just leaving it playing like this to see if it gets over itself in time... it seems not to.

    Anyone else seen anything like this?

  • I've certainly been to that page before. :) Let's go through. Reminder that I am only playing up to 1080p/i media...

    And confirmed that the screen resolution in playback matches that. ie: Kodi/LE12 isn't upscaling to the TV's actual 4K capability.

    (Note to self: remember to try the player-process-info display next time it happens, see if there's something weird showing up then. right now while it's behaving itself, all seems sensible.)

    There's no whitelist in operation. Per above it seems to be picking the correct mode by itself. 1920x1080@50Hz. NB: as that's the vast majority of the media I play, I set the GUI to show in the same mode so there's no switching necessary on playback start/stop.

    Adjust Refresh was set to Always, now to On Start/Stop. I probably changed this before though without effect, with Always just being where I left it the last time. Also, per the above: it's on the right refresh rate already. Sync playback to display is on. When that's in play the effect tends to be that the audio pitch-shifts a bit on playback-start until it figures itself out, not frames - and whole seconds - being skipped some time later. ;)

    The Deinterlacing issue mentioned doesn't seem to affect me: Because there's no whitelist, the 1080p@25 mode that the TV has is enabled. I actually want this for the 25p media (transcoded that didn't need deinterlacing). But for an interlaced source it appears to be doing the right thing anyway and picking 1080p@50 (and using bwdif). Am watching live TV right now and it's perfect.

    Also, when it goes wrong, it doesn't go wrong in that way. It can be playing perfectly for ages then start behaving in the erratic manner described before. It's not just picking the wrong frame rate. Ditto with progressive source media. (Often transcoded *with* deinterlacing applied then.)

    4K@60/HDR - not using those formats. The cables involved have been successfully used with an AppleTV 4K so they should be fine for this lesser requirement.

  • Had to wait for it to happen after the first change - the switch-refresh-rate setting from always to start/stop - which it did. Now disabled sync playback to display.

    OFC there's a reason that setting was on. :) That buttery-smooth playback even when the TV and/or GPU can't *quite* sync to exactly 23.976Hz or 59.96Hz (IIRC), and me being unreasonably sensitive to the occasional skips or dupes when that setting is off. I've defaulted to having that setting on for years, since it was implemented in Krypton I think? and never had this problem on past (generally PC-based) hardware. Hence again wondering about RPi5 kernel clock issues...

    So we'll see. Waiting to prove a negative again...

  • OK, a week after that config change (turning off sync playback to display), and the issue hasn't recurred, so it's looking likely that was the problem.

    Although I have had periods of it not recurring longer than that before, so this post doubles as an attempt to call-out sod's law and trigger it now. ;) But it was occurring quite a lot right up to when I made this change, so that's encouraging. I hate trying to prove a negative...

    Still maintain sync playback to display ought to work and it's a bug that this happens... but for anyone else searching for this problem, this looks like being the workaround. FWIW I also haven't seen the sort of artefacts that originally pressed me to turn that setting on, though I also haven't been watching very much of the kind of content that most shows it up. (Smooth-flowing motion in a fractional frame rate.)