I've been seeing a recurring issue in Kodi on Windows clients (independent of hardware) where a given WTV file will play to a certain point and then glitch, and Kodi will jump ahead to a later part in the recording, then continue to play. When it happens, the playback position on the seek bar will turn *negative*, breaking accurate backward and forward seeking. The only way to correct it is to stop playback and play the recording again, often by skipping *just* past the point where the glitch happens in the particular recording, or it will tend to re-occur. That said, it doesn't *always* re-occur at the same point, but often does. It happens pretty often to me, say a few times a week on recordings.
I want to say it's been happening more frequently since Kodi 18, but I can't say for sure. I've seen it both when using the PVR WMC addon for playback *and* when playing the recordings directly through the main Videos section, so it's not specific to the PVR WMC add-on. Sometimes it will glitch on the add-on, but then the same position *won't* glitch when directly played from Videos, so it's not consistent or easily reproducible. A theory is that it's an issue with Kodi's error handling of the WTV format when some frames are lost over the network? Maybe Kodi runs into small errors in WTV TV recordings and doesn't have good logic to handle these? You'd hope that error handling could still work around this sort of error.
Anyway, I don't have clear steps to reproduce, nor do I have any useful logs. I'm just putting this out there so maybe someone else can confirm the issue.
Configuration: Server is a low-end Windows 10 netbook, with the recordings stored on a USB 3.0 external drive, and the server is wired over Ethernet to the router. The client computers access the recordings wirelessly. The files are recorded with WMC from OTA TV.
Next time I see it happen, I guess I could try moving one of these recordings to a thumb drive to test on a Kodi client locally, but given that it doesn't always happen even on the same file, I suspect it's not necessarily file corruption or even TV signal corruption, but dropped frames over the network?
I considered testing the ServerWMC setting "remux the playback of all wtv files" to see if it might help, but my ServerWMC machine just isn't powerful enough to handle this in real-time, even when putting the remux share on an SSD and experimenting with the RemuxRecoverTime_MS setting. Obviously, remuxing/converting the files to another format would probably workaround the issue, but this would be very time-intensive.
Thanks!
It's probably not the same thing, but around Christmastime last year my PVR addon started having serious problems on Windows. The problem was also coincidental with an upgrade to Windows 10 1909 and/or the Microsoft December patches. It's hard to know exactly what went wrong, but my Windows-based Kodi systems went bonkers.
What fixed everything on Windows for me was this PR:
https://github.com/xbmc/xbmc/pull/17097. It was only supposed to help with a long-standing problem I've seen with an audio drop out on some PVR channels, but it unexpectedly ended up fixing all of my Windows concerns (Note that the fix was actually from @
FernetMenta, not me, I'm not that smart - lol).
It's just that the symptoms you describe are eerily familiar to what I was seeing, though. If possible, maybe try a Leia nightly newer than 1/1/2020, it will have that particular change in there. I haven't seen a single problem since the PR was integrated. Literally went from 15-20 instances a day to zero.
Hope this helps, and hope that the PR ends up being magic for you too
(2020-01-26, 06:33)djp952 Wrote: [ -> ]If possible, maybe try a Leia nightly newer than 1/1/2020, it will have that particular change in there. I haven't seen a single problem since the PR was integrated. Literally went from 15-20 instances a day to zero.
Hope this helps, and hope that the PR ends up being magic for you too
Good idea to at least rule out anything that's recently been fixed. Thanks, I'll follow back up once I've tested it.
Unfortunately, it just did it again on the Leia nightly, so back to the drawing board.
Are you on 1909 (19H2)? It looks like there have been some scheduler changes in this build. I had far less problems setting the Kodi process priority to "High" in Task Manager as well. I may propose some changes to set the thread priorities based on their function, a quick test last night just telling Windows every thread in the app is "Playback" (which is not right, just a test) also solved the problem.
I can replicate a Kodi glitch on 1909 really easily. Have Kodi windowed and playing back something and open something that will spike the CPU to 100%. Kodi gets starved out for a couple seconds. Could even be the various Spectre/Meltdown patches as they keep being refined, I have taken quite a performance hit on Windows PCs.
Anyway, sorry the nightly wasn't of any value. Maybe we will find more people starting to have problems with Windows and can help narrow it down to the OS or the application
(2020-02-02, 20:05)djp952 Wrote: [ -> ]Are you on 1909 (19H2)?
Yes, the Kodi client that I most often reproduce this issue on is, but I'm pretty sure it happened prior to 1909.
(2020-02-02, 20:05)djp952 Wrote: [ -> ]I can replicate a Kodi glitch on 1909 really easily. Have Kodi windowed and playing back something and open something that will spike the CPU to 100%. Kodi gets starved out for a couple seconds. Could even be the various Spectre/Meltdown patches as they keep being refined, I have taken quite a performance hit on Windows PCs.
I'm most often in windowed mode when it happens. That said, when you replicate such a glitch, does it jump forward an unpredictable amount of time much further into the video, and then if you try to use the arrow key to skip back 10 seconds, does the time position go negative? *That* would be fully reproducing this. It might have to do with how WTV files perform when streamed over a network -- maybe their content isn't muxed in a robust way? What's absurd about this issue is that I can restart the video, go to the same position three or four times and reproduce the exact glitch, but maybe on the fifth time, it plays back at that position perfectly fine. I just can't explain that.
I can't say that I've duplicated that particular scenario. For me, and I'm not using the same PVR that you are, playback will jump forward to "realtime", which is usually a couple/few seconds from the point of the glitch, and depending on if the source is Live or Recorded, it may show a buffering circle. From that point it's good, no issues with the time/seek bar.
In my experiences to date, problems with things like negative time are a problem with the "GetSeekTimes()" callback. Perhaps when the glitch occurs something goes awry with pvr.wmc's implementation of this function? On the surface it looks like it tries to do some caching of those values, maybe when something bad happens those values become no good and in theory could cause negative times.
That can't be, OP says it can happen independent of the addon, i.e. just playing the file from the videos section. I would be interested to know if the files that show this problem are mpeg2 or avc(H.264) format (I am betting on the latter).
(2020-02-03, 19:30)krustyreturns Wrote: [ -> ]That can't be, OP says it can happen independent of the addon, i.e. just playing the file from the videos section. I would be interested to know if the files that show this problem are mpeg2 or avc(H.264) format (I am betting on the latter).
Nope, hitting O on the keyboard during playback displays the video decoder as "ff-mpeg2video..."
Good thing I didn't bet anything. That is weird. Have you tried playing one of these files in something other than kodi?
(2020-02-04, 22:20)krustyreturns Wrote: [ -> ]Good thing I didn't bet anything. That is weird. Have you tried playing one of these files in something other than kodi?
I actually don't think it's the files, because it will only glitch for a few repeated playbacks at the said time stamp (wherein I stop the file completely, play it fresh, skip ahead to just before the previous glitch point, let it play, it glitches, then repeat these steps, that is, stop the file completely and play it fresh). After a few rinses and repeats, it *won't* glitch at that point anymore, which sounds absurd, but true. The fact that it acts this way also seems to cast doubt on it being a network error or dropped frame, because it *will* glitch at the same point for multiple do-overs before it resolves itself and no longer glitches. Maybe it could be some sort of glitch at a lower level than Kodi, like when the server's external hard drive can't seek fast enough when skipping ahead, and then some sort of read buffer compounds the issue where it repeats the error on successive playbacks until the buffer is cleared? I just don't know. I'll have to see if I can get a screen capture of the behavior.
(2020-02-02, 20:05)djp952 Wrote: [ -> ]Have Kodi windowed and playing back something and open something that will spike the CPU to 100%. Kodi gets starved out for a couple seconds.
I think you're right, that if you have it windowed and playing back, and then, say, have a browser open streaming another video in the background, it increases the chances of these glitches.