[mmortal03]

A lot of people have mentioned an issue where their video playback is choppy unless they keep moving the mouse over the video, but I'm having the opposite problem! On Windows with Kodi 17.6, whenever I have Live TV playing, it plays perfectly fine, but as soon as I do anything to make the controls appear below the video (by hovering the mouse, for instance, or just calling the interface from the keyboard), the video and controls grind to a halt to the point where Kodi gets close to freezing. For comparison, this freezing is similar to, in windowed mode, right clicking on the title bar while a video is playing, but, in this case it's whenever the Live TV time shift controls appear. When this happens, if I just let the controls auto hide again, the Live TV picks back up and plays perfectly fine again. I'm not seeing the issue with other videos -- just on Live TV. (I'm using ServerWMC, btw.) The freezing or choppiness is so bad that I essentially have to use the keyboard 'x' to stop the video, because it becomes very difficult to move the mouse to the stop button so that I can stop the video so that it will stop grinding to a halt. Like I said, I've noticed that this problem is only with Live TV thus far. If it's a recorded TV program, or an MKV video, for example, I don't have this problem with the controls freezing/locking up Kodi. Furthermore, this problem did not occur back in Kodi 16.0 (I've just tested it to double check). I've tried messing with all the video settings in Kodi that I can find, but, so far, nothing has solved it. Also, I'm not having this problem on Android, only on Windows. Are there any settings relevant to the Live TV playback controls or timeshift settings that might account for this?

[mmortal03]

I will provide a debug.log and video of the behavior as soon as I can.

[krustyreturns]

Pvr.wmc and serverwmc have no notion of whether the OSD is present, the osd and the playback of the video stream are all handled by kodi.  So there is really not anything we can do about this in the pvr addon (until I am proven wrong anyway), it seems more to be a kodi/windows issue, and might possibly be particular to your machine.  Do you have another windows machine to test this on?

[mmortal03]

Hi krusty,

Yep, I've tried it on two machines so far. Both are Windows 10. One is an i7-2635QM laptop, with 8GB RAM, tried with both its Intel HD Graphics 4000 and its Nvidia GeForce GT 640M. The other machine is an i5-4570T PC, with 6GB RAM and Intel HD Graphics 4600.

[krustyreturns]

Post the serverwmc log (on pastebin.com) after you have recreated the problem, maybe there will be something there.

[mmortal03]

Post the serverwmc log (on pastebin.com) after you have recreated the problem, maybe there will be something there.

 Hi krusty,

I've just tested it myself by taking note of the exact minutes that I caused the Kodi timeshift and controls to appear (which is when the freezing happens), and then comparing those times to the server log. The only item that occurs in the server log that corresponds with the freezing is when there was a "Received client request" for "GetBufferTimes". However, while these events happened every time that the problem happened, they *also* happened at a few points unprompted where the freezing *didn't* occur. This makes me think that something else other than GetBufferTimes also is happening around the same time, either on the client side or server side, but doesn't get logged to the server log. On the Kodi client side, however, there's much more to see. The following errors in the Kodi log *directly* correspond with the freezing: 

15:44:13.456 T:8084 WARNING: Previous line repeats 11 times.
15:44:13.456 T:8084  NOTICE: CVideoPlayerAudio::Process - stream stalled
15:44:16.260 T:10036 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
15:47:14.390 T:8084 WARNING: Previous line repeats 9 times.
15:47:14.390 T:8084  NOTICE: CVideoPlayerAudio::Process - stream stalled
15:47:16.448 T:10036 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
15:52:14.536 T:8084 WARNING: Previous line repeats 17 times.
15:52:14.536 T:8084  NOTICE: CVideoPlayerAudio::Process - stream stalled
15:52:17.560 T:10036 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer


And here's about 20 seconds of more verbose output, for a different time that it happened, starting with the mouse over (Pointer.xml) event. You can see the "timeout waiting for buffer" events happening soon after the controls popping up: https://pastebin.com/egNbsuMP

[krustyreturns]

Hi,

My guess is that you are probably correct that those 'stream stalled' warnings in the kodi log are related to the problem.  It seems to know for sure - since you don't have this problem with your android client - would be to see if they get triggered by the android osd.  If you are right, then they shouldn't get triggered.

If the stream that is getting stalled is the one from swmc I can't see why the osd would have any effect since swmc doesn't know when the osd is active.  Swmc does report problems with the swmc stream though if they are ocuring, so you might look at the swmc log to see if it is reporting buffer problems during those times.  Or post the log on pastebin and I can look at it (but then I need to know the times to look for).

The frequency of GetBufferTimes calls can be decreased by changing a setting in swmc, in the setting file of swmc change the value of BufferCountFilter to a value much bigger then its default value of 100 (like say 10000).  But I doubt that is causing the problem too.

[mmortal03]

The frequency of GetBufferTimes calls can be decreased by changing a setting in swmc, in the setting file of swmc change the value of BufferCountFilter to a value much bigger then its default value of 100 (like say 10000).  But I doubt that is causing the problem too.

 Maybe we were both wrong, lol, because after trying that, I'm no longer seeing it freeze when the timeshift controls appear.  What are the consequences of setting it to a much higher value? I'm not convinced that doing this fixes everything, as I'm still seeing some freezing in other circumstances, but this makes it at least usable. Figuring out *why* this is happening is probably next step.

[krustyreturns]

Yeah us both figuring that it's not the problem is probably what cinched it.  Are your android clients running an older version of kodi?  Possibly one that doesn't call getbuffertimes at all?

When kodi queries the size and location of the time shift buffer, pvr.wmc send a getbuffertimes call to swmc.  These queries are to update the OSD display of the timeshift.  When I was coding it, I noticed kodi calls it a lot, way more times then I thought was necessary to update the osd, so I put a filter in so that many of the calls are ignored (by default, only one out of a hundred calls get new data).  Have you tried increasing it even more?

[mmortal03]

Are your android clients running an older version of kodi?  Possibly one that doesn't call getbuffertimes at all?

 

Nope. It's 17.6 on there, too. I can do some more testing to see if I can reproduce the issue on Android, but so far, only Windows clients.
 

Have you tried increasing it even more?

Yeah, I've got it set at 50000 at the moment, just to see.