Kodi Community Forum
v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
---- Thread: v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0) (/showthread.php?tid=298462)



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - fritsch - 2019-02-03

Most likely the COL_Conversion in one of the shaders (again). We will see ...


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - facecreator - 2019-02-03

I also tried windows now. There are no mistakes.
8.2.5 does not support our processors (J5005). I also tried the builds of "sky42". That's 8.2.5 with J5005 support, also there is the error.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - rykios - 2019-02-03

Similar feedback from me too
First i downloaded & tried to boot with 8.2.5, does not boot at all, error message is  "Failed to start xorg. Is your GPU supported?"
Then i also tested using kodi 8.2.5 in sky's libreelec builds. Results as expected: boots fine, everything works fine, but, artifacts are there.
If i get that right, sky's build is "old solid kodi + new cutting edge linux" Which tell me that whatever problem is NOT within Kodi itself, but linux part ( new generation graphics drivers i assume )

I am also thinking this could be due to a bad batch of 5005 processors... If only we 3 are having this problem.
I am about to make a clean install of newly released LE 9, i was planning to do that anyway Smile
Me personally, i can live with this bug, its not a showstopper Wink
Appreciate all your efforts guys


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2019-02-04

(2019-02-03, 22:44)rykios Wrote: I am also thinking this could be due to a bad batch of 5005 processors... If only we 3 are having this problem.

Or a duff BIOS? It is strange.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - cirkator - 2019-02-04

I have the same problem. NUC7PJYH with libreelec 9.0.0. Had the problem on your builds as well.
Don't really mind either...


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - facecreator - 2019-02-04

I just tried build # 701. There it looks like the error does not exist. Can that confirm who? Will continue testing.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2019-02-04

New LibreELEC.tv Leia build #0203: Generic
(Supercedes previous build)

SHA256 Checksum: c96dc58a6afe680495c611a39eb4a4e2152b99d04f7bd442b3d83bdb57b59eae (Generic)

# uname -a
Linux NUC 4.19.19 #1 SMP Mon Feb 4 00:18:04 GMT 2019 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20190204000903-#0203-g974f4cb [Build #0203]

# Kodi version
(18.1-RC1 Git:077fde4). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (974f4cb, changelog) and tip of XBMC master (077fde4, changelog) with the following modifications: Build Highlights:
  1. Switch to multi-threaded build system
  2. Updated devel packages: glibc, glib, binutils, meson, ninja etc.
  3. linux: add patch to fix Zotac IR remotes
  4. VideoSync: Fixup vsync clock
  5. EPG - Delete timer 'All' option fails to delete timer rule
Build Details:
  1. XBMC:
    • VideoSync: Fixup vsync clock (PR:15403, 1 commit, 2 files changed)
    • RenderCapture: Only query Occlusion if GL lower 1.5 (PR:15351, 1 commit, 1 file changed)
    • [skins] Estuary + Estouchy keyboard layout fixes (PR:15399, 1 commit, 2 files changed)
    • EPG - Delete timer 'All' option fails to delete timer rule (PR:15410, 1 commit, 1 file changed)
  2. pvr.mythtv:
    • fix user injection issue (3c104f7)
  3. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] patch: Bump devel packages, add multi-threaded buildsystem
    • Added: [env] PR:3289 (perma): linux: add patch to fix Zotac IR remotes
    • Updated: [pkg] PR:177 (perma): Recording edls (pvr.vuplus)
    • Updated: [pkg] PR:14571 (perma): Remove ARB postfix from GL functions



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2019-02-04

Weekly Linux 5.0-rc5 build #0203x: Generic

Known issues:

xf86-video-nvidia and xf86-video-nvidia-legacy NOT enabled (not yet compatible)
No dvb-latest or crazycat drivers



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - umtauscher - 2019-02-04

(2019-02-04, 00:09)Milhouse Wrote:
(2019-02-03, 22:44)rykios Wrote: I am also thinking this could be due to a bad batch of 5005 processors... If only we 3 are having this problem.

Or a duff BIOS? It is strange.
Well I have it too. i suppose it's a problem with the Intel grafics driver? at least it looks that way to me.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - rykios - 2019-02-04

Aha! 5 people so far with this bug   ...and counting Cool
I tell you brothers we are not alone  there must be more of us hahahaha

Now, on the serious side, today's fact: I have been looking my amazon transaction history, and i see i got some new fancy HDMI cables last SUMMER, July 5 actually. Means the problem was there at end of June, in case this rings some bells...
At a first glance, typical symptoms of a Intel graphics drivers issue.... though the more i think about it, the more i feel its a hardware issue... Some bad batch.
Maybe we all should join forces and ask for a hardware replacement, even if guarantee has expired Tongue


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - umtauscher - 2019-02-04

not for me. My nuc is just a few weeks old. So I suppose a "bad batch" is not the problem here.
On the other hand, since it only happens on the home screen, I am pretty sure it's a software issue.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2019-02-05

New LibreELEC.tv Leia build #0204: Generic
(Supercedes previous build)

SHA256 Checksum: 5e4d4f176171834490e60a29de7c5a0fa35b82c20dcc94f000af5f73cc690910 (Generic)

# uname -a
Linux NUC 4.19.19 #1 SMP Mon Feb 4 21:27:58 GMT 2019 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20190204211109-#0204-g974f4cb [Build #0204]

# Kodi version
(18.1-RC1 Git:35a2613). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (974f4cb, changelog) and tip of XBMC master (35a2613, changelog) with the following modifications: Build Highlights:
  1. [PVR][settings] Reintroduce setting "Close channel OSD after switchin
  2. Fix binary add-on symbol stripping
Build Details:
  1. XBMC:
    • Fix Top 100 Albums regression (PR:15422, 1 commit, 1 file changed)
    • [Fix]Avoid attempt to load music info for smartplaylists (PR:15353, 1 commit, 1 file changed)
    • [Threads] revert #15263, log tid instead posix thread (PR:15419, 1 commit, 5 files changed)
    • [PVR][settings] Reintroduce setting "Close channel OSD after switchin (PR:15420, 1 commit, 5 files changed)
  2. vfs.rar:
    • Fix infinite loop when attempting to read from invalid file (PR:32, 1 commit, 1 file changed)
    • bump to version 2.0.6 (45a0cec)
  3. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] patch: Bump devel packages, add multi-threaded buildsystem
    • Updated: [env] PR:3260 (perma): linux (RPi/Generic): update to linux-4.19.19



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - facecreator - 2019-02-05

Hello,
I once asked in the intel forum for the error. The following was written there.
Click


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - umtauscher - 2019-02-05

Well, if I'm not mistaken, the i915 module doesn't exist in LE.
BTW I put the NUC to another TV and the areas affected are now outside the visible area. (Overscan I suppose)
So I'm good for now. ;-)


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2019-02-06

@umtauscher the i915 driver is a kernel built-in with LibreELEC.

(2019-02-05, 17:26)facecreator Wrote: Hello,
I once asked in the intel forum for the error. The following was written there.
Click

Nice find. Try adding i915.enable_fbc=0, sounds like that should work but don't know if it has any side-effects. Could be the only work-around until there is a bug fix.

Might be worth adding a comment on the bug that it is also reproducible with LibreELEC, just in case LibreELEC is easier for anyone else to test against. It's been set to a medium priority, not really sure what that means but probably don't hold your breath waiting for a fix (last update: 3 months ago).

Can't remember, but did anyone try testing with the linux 5.0-rc kernels and see if it's still present?