[krustyreturns]

I guess I am left with wanting to know if reverting back to gotham really does fix the cpu issue, have you tried that yet?

[tufkal]

So you did test Kodi playing back the completed ts file right? And that was ok? If so it's even weirder that it only has trouble with the "growing" ts file

Kodi has all sorts of hardware/software decoding settings etc (iit uses ffmpeg and there certainly would have been newer ffmpeg changes included in Kodi compared to XBMC) so I do think it more likely to be your Kodi configuration than anything else. What video card do you have? Dilligafs suggestion will be good to test. Also confirming my question above about ts file playback after remux has finished, and checking video file information (O on keyboard while viewing)

OK, so I watched a minute of "Parks and Rec" after turning on the option to leave the temp files, and then I watched the .ts temp file from Kodi's file manager. I used the video info overlay during both, here ya go:

Live TV (stutters, desync)

Code:

D(Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.0(side), 384kb/s
P(aq:15%, Kb/s:463.42, att:0.0dB)

D(Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), tuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], max. 80000 kb/s)
P(fr:25.000, vq 75%, dc:ff-mpeg2video, Mb/s:13.12,drop:4, skip 154, pc:none)

C( ad: 0.000, a/v: 5.119, edl:-,dcpu: 0% acpu: 0% vcpu: 0% cache:0 B 88%)
W( fps 16.18 CPU0:100% CPU1:100%)

Kodi playback of TS file (perfect)

Code:

D(Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.0(side), 384kb/s
P(aq:94%, Kb/s:377.97, att:0.0dB)

D(Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), tuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], max. 80000 kb/s)
P(fr:120.000, vq 92%, dc:ff-mpeg2video, Mb/s:10.81,drop:0, skip 4, pc:none)

C( ad: 0.000, a/v: 0.057, edl:-,dcpu: 0% acpu: 0% vcpu: 0% cache:0 B 89%)
W( fps 22.18 CPU0:54% CPU1:62%)

Looks like some good data here to pinpoint what's going on. What do you make of it Scarecrow?

[tufkal]

I guess I am left with wanting to know if reverting back to gotham really does fix the cpu issue, have you tried that yet?

I could maybe try that this weekend, and of course I would be doing it in hopes if this is a bug in Helix that we can get a dev and get it fixed (because I don't want to use Gotham).

[scarecrow420]

well i guess i didnt expect any differently but that info shows that the audio/video appear to be detected the same etc. It shows 100% CPU on the live TS whilst the static TS is 40-60% CPU (which still sounds quite high really). I would have expected hardware acceleration to be occuring but im no expert. Have you looked at the hardware acceleration options in Kodi settings? Are your video card drivers all good etc? Also a weird question but what audio path are you using? Are you using HDMI for audio? And are you using DirectSound or WASAPI? I have had stuttering and such when using DirectSound to my receiver and need to use WASAPI

Also could you post a Kodi debug log while the problematic playback is occuring as I think so far you have only posted ServerWMC logs and there might be info on the Kodi debug log that could help

[tufkal]

well i guess i didnt expect any differently but that info shows that the audio/video appear to be detected the same etc. It shows 100% CPU on the live TS whilst the static TS is 40-60% CPU (which still sounds quite high really). I would have expected hardware acceleration to be occuring but im no expert. Have you looked at the hardware acceleration options in Kodi settings? Are your video card drivers all good etc? Also a weird question but what audio path are you using? Are you using HDMI for audio? And are you using DirectSound or WASAPI? I have had stuttering and such when using DirectSound to my receiver and need to use WASAPI

Also could you post a Kodi debug log while the problematic playback is occuring as I think so far you have only posted ServerWMC logs and there might be info on the Kodi debug log that could help

The reason the static TS playback CPU usage is not 10%-15% like you would expect was because of some overhead from TeamViewer, which i was using so I could take screenshots of the playback overlay info. If I had been using my wireless keyboard and mouse in front of the TV, the CPU usage on the static would have been what you would expect.

All the hardware acceleration options are turned on in Kodi. I am using HDMI for audio and video, and the receiver for my speakers comes after the TV (using TV's audio out). So it's just a single HDMI cable from HTPC to TV.

I'm beginning to think it's a Kodi bug, possibly related to ffmpeg or one of it's internal software dependencies that changed in 14.x.

The part I can't understand is how am I the only one who has had this happen? Am I the only person in the world who uses 14.x, ServerWMC, and the Windows version of Kodi as a client?

I have several RaspberryPi lying around, I could always setup the folder share in ServerWMC and install OpenELEC on a Pi, and make it all work that way (assuming the linux arm build doesnt have the same ffmpeg/whatever bug).

Does anyone here use the Windows Kodi client along with WMC & ServerWMC? I know most client setups use Linux, but I can't be the only one using Windows.

[scarecrow420]

I'm using Windows but I'm on comparatively strong CPU with integrated graphics that does hardware acceleration, eg i3 haswell NUC and broadwell celeron nuc

I still think it's a hardware acceleration issue, can you post a Kodi debug log?

[tufkal]

OK, so I figured it out.

It was a bug in Kodi, and I will file a report for it as soon as I can. You were right scarecrow, it had to do the with hardware acceleration settings in Kodi.

As you suggested scarecrow, i started looking at actual Kodi logs instead of PVR logs, and I found a few lines during live TV playback that were different from straight file playback. Kodi was using different video decoding accelerators for some reason. I have Hardware Acceleration set to 'Auto Detect', which is the default, and also is where the problem was. When I was playing a local file, it was using DXVA hardware acceleration. When I was watching a muxing .ts file (Live TV) it was using software rendering.

I have no idea why it chooses to detect differently, or what change from 13.X -> 14.x, but that did the trick. I chose the acceleration method manually using DXVA instead of 'Auto Detect' and LiveTV is working perfectly again, like it was in Gotham. No stutter, no desync, normal CPU usage.

So apparently......a static .ts file and a dynamic .ts file get detected differently and the code chooses software rendering for dynamic(live) files. That's the bug. Manually choosing DXVA fixes it.

So I guess that part of code in Gotham worked better, or Auto Detect wasn't an option in Gotham and it just went top to bottom trying to find acceleration. I don't know for sure, all I know is that I am happy I found a solution and that my HTPC is 100% working again!

Thank you all for your help digging into this problem, and helping me find a solution. Hopefully this thread can help other users who might have PVR issues where the wrong decoder is chosen for live/dynamic .ts files.

+1 scarecrow420
+1 ServerWMC, krusty and his team
+1 Kodi