[theghost3131]

It's working thank you very much for you patience and time. I didn't know that a new library to replace X11 was created...

[camelreef]

@camelreef I just came home and tested the complete sample on my ASRock J4205. No problems at all. I use intel driver + DRI3 + a drm-tip kernel from some time ago. I am starting to think that something else on your system (running next to kodi) causes your issue by either blocking the CPU or even causing interference - DVB card? Some server process acting up?

I watched the complete 15 minutes. I also opened the OSD randomly, as the Codec-Info - no issue. Poor fox, nice eagle - funny how they got the camera on top of her (they told the eagle is a her). What an eagle fight - like Karate kid. Now I got hungry ;-)

Mesa 17.2.2
xserver-xorg-video-intel: 2:2.99.917+git1711090734.37a682~oibaf~z <- I recompiled fabio's latest version (but should work with everything else)
Kernel: drm-tip intel (2 weeks ago)
xserver: 1.19.5-0ubuntu2
vainfo: Driver version: Intel i965 driver for Intel® Broxton - 1.8.3
NFS-share via 5 GHz AC Bridge
DTS-HD passthrough enabled.

Well, the box is used for 3 things: Kodi, Roon server (well-behave in my experience, but I will give it a go with the service turned off) and Samba. I've cleaned-up a few other things that were running by default and knew I would not need (lxcf, snapd...).

Here is a ps -ef:
http://paste.ubuntu.com/26210536/
Hardware-wise, it's just the NUC (CPU, RAM, SSD) and an external USB3 HDD.
I'll put a 4K movie on the SSD, and get the somewhat CPU-hungry NTFS out of the way. But when I test the live nightly LibreELEC, it's the same disk and mount...

mesa: 17.3.0~git20171212+17.3.49a612d1-0ubuntu0ricotz~17.10.1
xserver-xorg-video-intel: 2:2.99.917+git20170309-0ubuntu1
kernel: 4.14.5 mainline
xserver: 1.19.5-0ubuntu2
vainfo: Intel i965 driver for Intel® Kaby Lake - 1.8.3
Files are local, but on an NTFS mount
No pass-through enabled

I kept playing/testing/logging this weekend, with the same results.

Also, that 15mn sample became a bit too short once I added the xorg-edgers PPA and other things, as the artefacts started showing after 30-40mn... Hence the switch to a full length movie, and my family getting very tired of Wonder Woman!
Wasn't it a crane in Karate Kid?



On a side note, the TV it's should be plugged into is a Sony Android TV. Guess what, Play Store -> Kody 17. I've tried it, pointed at the Samba share, perfect play of Wonder Woman 4K HDR... I have a fall back solution. Not one I would like to implement, though, as it would involve playing with ARC and such... But it works!

[fritsch]

What does this wpa_supplicant do? It does not scan for networks and "shortly" replaces the default route or something?

[camelreef]

What does this wpa_supplicant do? It does not scan for networks and "shortly" replaces the default route or something?

 It's used for the Wi-Fi connection and associated crypto. Sure, it can scan, and potentially mess-up the network connection (though that has been fixed a while ago). But the files are local, on an external USB3 HDD, access as a local filesystem, not Samba, and thus should be unaffected

[camelreef]

I am starting to think that something else on your system (running next to kodi) causes your issue by either blocking the CPU or even causing interference - DVB card? Some server process acting up?

Well, the box is used for 3 things: Kodi, Roon server (well-behave in my experience, but I will give it a go with the service turned off) and Samba. I've cleaned-up a few other things that were running by default and knew I would not need (lxcf, snapd...).

I did a test with Roon server stopped. Same result, artefacts after 30-40mn.

Now doing a test with the movie file on the SSD, ext4 FS, and the external USB3 drive unmounted.

[camelreef]

Now doing a test with the movie file on the SSD, ext4 FS, and the external USB3 drive unmounted. 

If I told you that I am more than an hour in the movie, and no artefact yet... Would you believe it? Hmmm... I'll need more than one sample to make the statistic valid.

ntfs-3g is CPU hungry, as a FUSE thing, and sometimes gets into a diminishing perfs ceiling for writing. It may have the same issue for reading...

It may be that LibreELEC is using the kernel driver that is read-only.

Well, if that's it, I'll make the FS ext4 and be done with it! I'll lose the ability to use the drive on Windows machines to load content, it will have all to be through the network share, which is acceptable to me.

More when I have more than 1 sample, and when I have taken a look at the NTFS driver used in LibreELEC.

[fritsch]

I most of the time compile kernels / or kodi next to playing videos ...

[camelreef]

I most of the time compile kernels / or kodi next to playing videos ...

 And I am sure that it works.

Here is my current theory: the artefacts are not linked to mesa, libva, X, CPU or GPU, but I/O perfs from the external USB HDD using a user-space driver for the file system. Sourcing files from a drive using the ntfs-3g fuse driver works until it hits a rapidly lowering performance ceiling, and then not enough data gets streamed for decoding, and I get artefacts.

I will take a look at the ntfs driver used in LibreELEC. I'm betting on the read-only but performant kernel driver instead of the FUSE ntfs-3g.

I also have a spare USB3 external HDD that I can format in ext4 or NTFS, and test with kernel and FUSE drivers for NTFS.

That would be quite en tangent as far as root cause is concerned, but there is credibility in my current path!

[camelreef]

I most of the time compile kernels / or kodi next to playing videos ...

 And I am sure that it works.

Here is my current theory: the artefacts are not linked to mesa, libva, X, CPU or GPU, but I/O perfs from the external USB HDD using a user-space driver for the file system. Sourcing files from a drive using the ntfs-3g fuse driver works until it hits a rapidly lowering performance ceiling, and then not enough data gets streamed for decoding, and I get artefacts.

I will take a look at the ntfs driver used in LibreELEC. I'm betting on the read-only but performant kernel driver instead of the FUSE ntfs-3g.

I also have a spare USB3 external HDD that I can format in ext4 or NTFS, and test with kernel and FUSE drivers for NTFS.

That would be quite en tangent as far as root cause is concerned, but there is credibility in my current path!     

 

---

My first test involved leaving the system as-is, but mounting that NTFS partition on the external USB3 HDD using the read-only kernel driver.
No artefacts whatsoever! (but probably played the wrong movie or not long enough, see below)
 

---

With that positive result in the bag, I booted the live LibreELEC stick and checked what it it using. I was surprised to see it use ntfs-3g too!

Code:

ntfs-3g 2017.3.23 external FUSE 29 - Third Generation NTFS DriverConfiguration type 7, XATTRS are on, POSIX ACLS are on

Ubuntu 17.10 uses

Code:

ntfs-3g 2016.2.22AR.2 integrated FUSE 28 - Third Generation NTFS DriverConfiguration type 7, XATTRS are on, POSIX ACLS are on

And that's a big enough difference...

I've manually installed ntfs-3g, libntfs-3g and libgrcypt20 from future Ubuntu 18.04/Bionic and got this:

Code:

ntfs-3g 2017.3.23 integrated FUSE 28 - Third Generation NTFS DriverConfiguration type 7, XATTRS are on, POSIX ACLS are on

I hoped that updating the ntfs-3g version would be enough, and that the integrated/external FUSE 28/29 would not make a difference. I also reverted to stock 4.13 kernel and purged the xorg-edgers PPA. I still have the VA-API PPA and the intel driver for X. I played again!

And....

Artefacts...

FUSE appears to make a difference, ntfs-3g is not enough... At least within the framework of my theory.
I've reverted libntfs-3g, ntfs-3f and libcrypt20 back to stock.
 

---

Next test!

I take a spare USB3 HDD, partition from scratch, ext3 file system, mount, copy the shapely Wonder Woman on it, add a source in Kodi, play!

And...

No artefacts!

Ah, but another movie with more movements is giving me artefacts...
 

---

I'm not too passionate about switching filesystem and lose OS portability for that external hard drive...

Something else hit me too: the Kodi on the TV played perfect 4K without artefacts, from the same hard drive, same NTFS filesystem, same old-ish ntfs-3g, same OS, same machine, with the added complexity of a Samba share and a Wi-Fi network!!!! Hmmmm.....

What if Kodi buffered things differently for network filesystems  than it does for local filesystems?

A quick Google, and there I land: http://kodi.wiki/view/HOW-TO%3AModify_the_video_cache

Oh oh! Cache values that I can play with! I also have plenty of CPU and RAM sitting pretty but idle...

So here I go with caching all, bigger read factor and 1 GB of RAM cache (3 GB of RAM used)

Code:

<advancedsettings>
  <cache>
    <buffermode>1</buffermode>
    <memorysize>1073741824</memorysize>
    <readfactor>40</readfactor>
  </cache>
</advancedsettings>

And nope... no go, artefacts quickly arrive.

a memory size of 0 to cache to disk (hoping that it uses the OS SSD) changes nothing.

Here is a debug log, just in case (yes, I've switched movie, that one has issues arriving more rapidly than the other)
 

---

I've also tried creating a source going through the local Samba server (hey, it worked for the TV...). Artefacts...

I've re-added the xorg-edges PPA, artefacts. I've re-added 4.14.5 mainline kernel... Artefacts...
 

---

I was sure that I was on to something! Darn!

Am I missing something around the cache settings?

Am I on the wrong path altogether?

What is LibreELEC doing that I am not doing on this install? (let me check again with Kingsman 1 is it really plays without artefacts, I'm starting to doubt everything...)

[camelreef]

What is LibreELEC doing that I am not doing on this install? (let me check again with Kingsman 1 is it really plays without artefacts, I'm starting to doubt everything...) 

I've tried again with Kingsman 1, off the NTFS partition on the USB3 HDD. Perfect, no artefacts. LibreELEC rules!

I want the same result on my Ubuntu!

[fritsch]

Where did you post your Debug Log again, when you were pressing "some key" while those artefacts appeared?

[camelreef]

Where did you post your Debug Log again, when you were pressing "some key" while those artefacts appeared?

 Didn't I post it? Doesn't sound like it.
I'll get one going tomorrow morning, after a good night of sleep, and when the TV is free again.

See you in a few hours!

[camelreef]

Where did you post your Debug Log again, when you were pressing "some key" while those artefacts appeared?

 Good morning from Seattle!

I woke up, grabbed a coffee, got in front of the Kodi, set debugging on, restarted Kodi, played Kingsman 1, and artefacts galore from the very beginning. "D" key used at each appearance of artefacts. With a special guests of white lines at the bottom of the screen.

• Kodi debug log: http://paste.ubuntu.com/26215792/
  

And then I remembered the drm debug from the kernel. So in I go setting Grub for it, reboot, and play Kingsman again. This time is was perfect to my eyes for at least 15mn, before artefacts appeared.

• Kodi debug log: http://paste.ubuntu.com/26215810/
  
• dmesg: http://paste.ubuntu.com/26215812/
  
• Syslog: http://paste.ubuntu.com/26215830/ (has the drm debug like dmesg, but with timestamps, easier to match with the Kodi log and the key presses)
  

Both times:

• up-to-date Ubuntu 17.10
  
• up-to-date nightly Kodi 18 PPA
  
• up-to-date VA-API PPA
  
• up-to-date xorg-edgers PPA
  
• mainline 4.14.5 kernel
  
• mesa: http://paste.ubuntu.com/26215854/
  
• vainfo: http://paste.ubuntu.com/26215856/
  
• id: http://paste.ubuntu.com/26215858/
  
• amixer: http://paste.ubuntu.com/26215860/
  

I do not like the fact that two different plays, with only a change in kernel logging and a reboot in-between, made playback crap out differently...

If there is anything else I can try, log, etc., just ask.

[fritsch]

The "ds" clearly show that whatever happened is totally unknown to kodi - nothing in the log. No resync, nothing - absolutely nothing.

Now - try - as asked some weeks before: Set your resolution to 1080p, play the same video again, let it scale down with "bilinear" scaling. Same artefacts?

[camelreef]

The "ds" clearly show that whatever happened is totally unknown to kodi - nothing in the log. No resync, nothing - absolutely nothing.

Now - try - as asked some weeks before: Set your resolution to 1080p, play the same video again, let it scale down with "bilinear" scaling. Same artefacts?

I know, nada in the logs, it's not good...
 How do I hard set to 1080p?