I’ve read “How to submit a useful support request” and will be collecting that info and edit it in (if I’m allowed to edit my posts), but first I thought I’d ask whether this is a recognised problem that might already have a fix:
I used OSMC Kodi 18.9 edition on a Raspberry Pi 3 for a long time, but recently decided to try and upgrade to the Kodi 20.2 edition thinking that any potential playback issues would be ironed out by now. Unfortunately I’ve been having playback problems since then.
I play a normal h.264 video, e.g. using the Youtube addon, and selecting 720p whereupon I get a h.264 stream. Here’s an example Youtube video that it happened in earlier today: https://www.youtube.com/watch?v=U_cKA8q2qk4. It also happens when playing normal video files (h.264 720p).
I pause the video after 5 minutes, and don’t interact with the system for maybe 30-60 minutes.
When I return and resume playback it starts playing but also skips/jumps ahead every few seconds from then on, making it impossible to hear complete sentences or follow along. Looking at the timeline it almost looks like it’s playing at twice the normal speed (with audio at normal speed but with gaps). Since I’ve never experienced this issue in Kodi 18, nor know of any Kodi player state that would produce such a result, I’m concluding that there may be a defect.
Manually jumping in the timeline does not fix the issue from this point onwards. Only restarting the video will help.
(Tried uploading videos demonstrating the problem but could upload neither .mp4 nor .zip)
This happens often enough after resuming from a long pause that it has become a pattern.
I’ll work on a debug log, although I don’t know yet how short a period of time I actually have to wait before the problem manifests. The trouble with the debug log is that when I enable it it also enables an always visible debug info overlay that I did not ask for, which ironically does not exactly encourage me to use Kodi normally (!)
Additional observations
It seems that the same symptoms can also appear if I leave a video file playing until I distinctly notice that the audio is out of sync with video (a less serious problem than the one this post is about, but they’re probably related), whereupon I press Ctrl+Shift+O to show the video diagnostics (name?) overlay. Doing that has not uncommonly resulted in the video starting to skip ahead uncontrollably, while the “missed: ” counter counts up rapidly (I don’t know exactly what it’s counting).
Disabling hardware decoding (“PRIME DRM”) in settings seem to fix the out of sync audio/video problems that I’ve had (the “less serious” problem mentioned in the bullet point above), leading me to believe that the problem described in this post is isolated to hardware decoding. Disabling HW decoding is not a solution as it renders most HD content unplayable.
Thoughts and suggestions welcome. Any specific tests that I should focus on, for instance?
When you moved from Kodi 18 to 20 was this with a clean install? If it was a clean install did you restore settings from a backup? Is this only happening with online content or is local media displaying this behavior as well?
It was an upgrade – not a new install (I currently don’t have spare SD cards for quick experiments and comparisons).
It happens to local content (from other sources than Youtube) as well; everything “local” is played over SMB, but yeah.
Thanks for the tip. I’ll use advancedsettings instead and try to capture the problem during normal use. Since it seems to happen all the time now, I think it’ll be straightforward.
I would suspect that there was an issue with updating between two versions that were years apart. I would recommend to backup your userdata with the My OSMC add-on and restore them to a clean install.
Hmm, that’s helpful to know – thanks for the tip. I don’t have intuition enough to pinpoint it myself. Any packages in particular that you suspect and that I could try reinstalling?
I think I need to hold off on experimenting with clean installs until I get some new SD cards.
As an aside even standard definition MPEG4 goes out of sync with audio within a few minutes whenever HW decoding is active during playback (it doesn’t jump forward though, so not as serious a problem). Meanwhile SW decoding gives flawless performance for the same file:
Media Info
Format : AVI
Format/Info : Audio Video Interleave
Format settings : BitmapInfoHeader / WaveFormatEx
File size : 300 MiB
Duration : 28 min 40 s
Overall bit rate mode : Variable
Overall bit rate : 1 463 kb/s
Frame rate : 25.000 FPS
Director : TSV Productions
Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings : BVOP1 / Custom Matrix
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Custom
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 28 min 40 s
Bit rate : 1 188 kb/s
Width : 576 pixels
Height : 432 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.191
Stream size : 244 MiB (81%)
Writing library : XviD 1.0.2 (2004-08-29)
Audio #1
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Format settings : Joint stereo / MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 28 min 40 s
Bit rate mode : Variable
Bit rate : 128 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 SPF)
Compression mode : Lossy
Stream size : 25.6 MiB (9%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (0.60 video frame)
Interleave, preload duration : 510 ms
Writing library : LAME3.90.
Encoding settings : -m j -V 4 -q 2 -lowpass 17.6 --abr 128
Language : English
I’m not versed in audio+video decoding so maybe this particular combination of codings (MPEG-4 + MP3?) is easily enough dismissed as problematic in and of itself, and/or isn’t related to the problem at hand. It’s just that the two problems seem to have coincided, and both seem to relate to “PRIME DRM”.
I got to thinking that since both pausing videos as well as leaving videos playing for some time result in problems, that maybe it’s mainly the time since starting playback that’s the issue, and that it therefore could be detectable even while paused:
I start a video and pause it within the first minute of playback.
I activate the Player Debug Info overlay (Ctrl+Shift+O)
I can see the “missed:” counter increasing. Very slowly at first: I left it at 15 half expecting it to not move, came back 10 minutes later and it was at around 300, after which it apparently ramps up; in the 3000-4000 range it increases with around 30 every second (probably faster the longer I wait).
So what is this counter counting? And what is it “missing” while the video is paused? Kodi documentation says this:
missed:10766 - Missedvblanks. VBLANK, is the time between the end of the final visible line of a frame or field and the beginning of the first visible line of the next frame
To me this description is a bit ambiguous; are they talking about the frames of the currently playing media, or the frames of the video signal output? Not sure – does this counter make sense to be increasing during paused playback?
The Player Debug Info overlay is described like this:
The Player Debug Info screen displays real-time dynamic data of the current audio/video streams.
I’ve always found xvid with mp3 audio to be a bit hit or miss regardless of which hardware or software I’m using. As far as where your issue is coming from my first inclination would be to look for a failed OS update but it is really a waste of time speculating what it could be. We ask for logs for a reason. I also don’t think it really makes the most sense to try to figure it out. Making a jump that big is prone to being problematic. A clean install should work well and since you are currently running an up to date version of Kodi you should be able to transfer your userdata without an issue. If I were you I would just pick up a new quality SD card and do a clean install on that. Backup all everything via My OSMC with your current SD and restore it on the new clean install.
Also the skipped frame counter in playerdebug is not necessarily indicative of an issue as showing that overlay itself can make that number climb even when there is no issue with the playback. Sync playback to display should be set to always or on start/stop if your connected to a regular display. That setting changes the output frame rate of the display to match optimally with the playing video to give the smoothest motion. Your issue is not with that setting.
Thanks for the input. I’ll give less weight to MPEG-4 + MP3 issues while isolating the problem.
I hear what you’re saying. When possible, I’ll create a new system for comparison.
Noted.
It consistently starts counting up rapidly after being paused for 10 minutes though, so for the moment I’ll let the working hypothesis be that a high count correlates with the problem. To me it looks like a cascade, but as you imply it’s possible that the more the counter needs to update the screen the quicker it might increase, so I’ll read it with a grain of salt and keep the overlay disabled for more useful numbes.
I think you’ve got the setting names mixed up – sync playback to display does not have the options you describe; it’s just a switch, and disabling it gets rid of the “missed:” counter entirely.
It might be coincidence, but so far everything seems to point to the same thing: sync playback to display is doing something weird after a long pause, causing what looks like the video player trying to “catch up” indefinitely. Now to try and recreate the problem with it disabled…
Update: preliminary conclusion is that the problem does not occur when Sync playback to display is disabled. Could not be recreated after 30 + 30 minutes of pause, so it’s looking good.
I did not expect such a feature to cripple playback to this extent. Weird. I can’t recall that feature ever having been a problem before (but also can’t say for sure whether I’ve actually used it extensively / had it enabled before – I could maybe check my settings in my OSMC+Kodi 18.9 backup disk image).
Well, I’ll be trying it out over the next day or two and then I’ll have a more definite answer.
Yea, sorry. I meant the allow refresh rate switching. It was a bit half asleep when I typed that.
That option is currently disabled internally so regardless of how the option is set it shouldn’t actually change playback. I know Sam put on his todo list to allow it to work if hardware acceleration was disabled (to allow changing playback speed) but I don’t think that work has been done yet.
As I understand it player debug has a lot of quirks and doesn’t always show you what you assume it to be. It is only intended by team Kodi to be used for debugging by programmers. When I read up on it years ago I saw discussions by Kodi team members to remove it from general releases as it was frequently misunderstood by end users what the various things actually meant. The OSMC dev that does a lot of this lower level video processing work has told me the skipped frames number in the debug overlay (this is a massively paraphrased) is not a reliable test metric and I’m okay with taking that as fact. Just because toggling that option makes the overlay display different numbers, doesn’t mean the video playback itself has actually changed.
It shouldn’t make a difference. If it is then that might be an indicator that there is an underlying issue with your update. I get that you don’t want to be stuck without a working setup and you don’t have an extra SD card laying around, but I think you’ll find that the amount of time your spending trying to figure this out is greatly in excess of the time it takes for a backup, clean install, and restore.
You may be right, it may take more time, and I appreciate that you’re trying to help me save excessive effort. I imagine you help lots of people here and from that perspective it makes sense to do what you propose, and I also completely understand if that is the extent to which you’re prepared to give advice.
At the same time, from my perspective this is only true if a clean install will indeed make a difference, which is not certain. Also I think that I have a bit of time to experiment, and a brain to do some edge-computing on which might result in something useful.
I’ve used others’ effort and solutions countless times so I dont mind experimenting a bit myself this time. I wouldn’t exactly call it fun, but it often turns out to be interesting, and I’ll blame only myself when it turns out that you’re absolutely right.
Worst case scenario I’ll learn to stay away in the future.
I’ve concluded beyond a doubt that disabling Sync playback to display resolves the issue.
Since I have a clear impression that there’s reduced confidence in the integrity of upgraded systems, and that the interest in debugging them is probably lower, I’ll hold off on sanitizing any logs until someone expresses an interest in them.
I’ve suddenly started experiencing this issue on my Raspberry pi 4. I set this device up around March 2022, and have allowed OSMC to patch it however it wants to on a frequent basis, without manual updating, so this doesn’t seem to be distribution upgrade related.
This is occurring on media that was absolutely fine a few weeks or months ago, and happens on all media.
@anohren As there are two of us, any chance you could get the OSMC team those logs so they can compare mine and yours? Perhaps unmark this as solved as well, as a fresh install doesn’t resolve it, and the other fix doesn’t fix it from the dev team PoV.
I’ll write up a full set of info/logs shortly (it takes 40 minutes to reproduce for me, and I need to get the log uploader to work!)
Well, it’s a shame that they’ve not replied once, much less acknowledged the defect, ever since I removed their only excuse to summarily dismiss the bug report as false by reproducing it on a fresh install — which since then has been regarded as wasted time and effort. That I’d spend more time producing logs would naturally not be time well spent from my perspective.
This thread is marked solved because of zero expressed interest from the team even after trivially reproducible on a fresh install. As such it was the right decision for me to not bother with the logs from the beginning. I said I was prepared to assist, from the start, but I’m not going to fight bug denial.
You don’t have to read minds. I’ve typed excessively here and been prepared to communicate all the way up to marking the thread as solved — what other semantics could “solved” have from my perspective?: If you’re the devs but I’m the one who can mark as solved then clearly “solved” does not mean “bug fix has been researched and developed”, but “thread owner don’t see any more progress being made here”. And I didn’t.
Perhaps if I had received a response other than incredulity and therefore dismissal of the existence of the defect I could have inferred some interest. “I can’t read minds” is my line.
I will see what I can do with regards to logs. And thanks for making OSMC.
I think the next few days will tell for sure whether my fix was placebo or not.