Stuttering/Laggy video playback when going from 8.90.006 to 8.90.007 on Haswell based Chromebox

**Drebbe** · November 16, 2018 at 7:09 PM

First time posting a problem. I hopefully have followed the wiki instructions correctly. Apologies in advance if I have not. Logs posted here Pastebin log

I have two Haswell based Chromeboxes (using the latest UEFI firmware from mrchromebox.tech), both work very well with 8.90.006 and all previous 8.90 alpha builds, but both have long delays pauses/stuttering/lag in video playback after updating to 8.90.007. Running kodi18-b5 on a Windows 10 box on same network connected to same NAS and the windows 10 box plays video flawlessly. Downgraded one of the chromeboxes back down to 8.90.006 and video playback returns to normal.

**Klojum** · November 16, 2018 at 8:09 PM Official Post

Code

<loglevel hide="true">-1</loglevel>

Disabling logging altogether will not tell us much what is going on. Use '1' instead of '-1' to enable debugging.

**Drebbe** · November 16, 2018 at 8:39 PM

Oops, forgot about that in my advancedsettings.xml file. I appreciate your patience with me. This log looks better (i.e., actually has useful info) Pastebin kodi log

**Klojum** · November 16, 2018 at 8:51 PM Official Post

Can you double-check if hardware acceleration is active while viewing your "39 steps" movie?

Press the letter 'o' during video play.

Code

14:28:18.223 T:139708148455168  NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10

For some reason, plenty of "content creators" are using 10-bit video streams, and your hardware is probably having a hard time keeping up the decoding via the CPU, as your GPU cannot do 10-bit video via hw acceleration.

**Drebbe** · November 16, 2018 at 9:37 PM

Video decoder: ff-h264-vaapi (HW)

Settings->Player->Video UI says VAAPI enabled.I watched the System CPU usage during 4 long lags, during the 1st, 3rd and 4th lag both cores stayed in the 20-40% range, during the 2nd lag, CPU #0 was pegged at 100% while CPU #1 stayed in the 20-40% range for the most part.

I created this MKV(H264) rip many years ago. Having same video issues with DVD rips (MKV/MPEG2) as well. Again, same Haswell/Chromebox hardware, playing same MKV/H264 video, running LibreElec 8.90.006 plays flawlessly.

**Klojum** · November 16, 2018 at 9:41 PM Official Post

Quote from Drebbe

running LibreElec 8.90.006 plays flawlessly.

That's weird.. I guess our real developers will have to take a look into that.

**Drebbe** · November 16, 2018 at 9:53 PM

OK, thanks for taking a look.

**chewitt** · November 17, 2018 at 3:52 AM Official Post

"MPEG-4 part 10" refers to a section of the H.264 specification. It does not mean 10-bit video (which is a problem on most hardware). If you look at the ffmpeg analysis a few lines before CDVDVideoCodecFFmpeg::Open in the log:

Code

14:28:18.222 T:139708148455168    INFO: ffmpeg[7F10568F9700]:     Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc

I've no idea what the problem is, but ^ that shows standard 8-bit H.264 video not 10-bit, so that's not the issue.

**Drebbe** · November 17, 2018 at 12:10 PM

Tried the Milhouse nightly LibreELEC builds to see if I could identify the day where the video playback issues started. 10/22 Milhouse builds and before are fine; video playback issues start with the 10/23 build. Still there in latest 11/16 build. Should I cross post my issue to LibreELEC-Testbuilds for x86_64?

**mglae** · November 17, 2018 at 12:15 PM

Code

Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0: AER: Multiple Corrected error received: 0000:00:1c.0
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0:   device [8086:9c14] error status/mask=00001000/00002000
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0:    [12] Timeout               
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0:   device [8086:9c14] error status/mask=00001000/00002000
Nov 16 14:28:04 HPElec kernel: pcieport 0000:00:1c.0:    [12] Timeout

This is already discussed in Milhouse testbuld thread on forum.kodi.tv.

Only work around so far is using kernel 4.18 or older.

**Drebbe** · November 17, 2018 at 1:24 PM

Thanks. I had been sticking to the official alpha builds, not the bleeding edge Milhouse builds. Very helpful to know there are others with the same issue. I'll follow the saga over at the Milhouse TestBuild forum going forward. Thanks Klojum, chewitt and mglae for responding and for the info.