Kodi Community Forum
v17 LibreELEC Testbuilds for x86_64 (Kodi 17.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: v17 LibreELEC Testbuilds for x86_64 (Kodi 17.0) (/showthread.php?tid=269815)



RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - fritsch - 2016-05-17

(2016-05-17, 15:25)diddle Wrote:
(2016-05-17, 15:06)fritsch Wrote: It seems kernel 4.6 is running really, really bad. Upgraded my Thinkpad T440s yesterday and even have screen flickering there ... it sucks hard, so I went back to 4.5.x. But more than filing bugs is not possible for us :-(

Don't know the LE guide lines here... but why not simply wait until severe show stoppers are fixed before adopting a new kernel (instead of always being on the bleeding edge)?

Cause you guys _find_ those show stoppers and then we can file bug reports. Kodi is a very special use case with immense pressure on hardware and drivers. We cannot rely on others to make this testing. The bugreports that came out of this thread had a very high value for now. Bugs are filed. That's the way OSS development works.

Updated logs with 4.6 (dmesg with drm.debug=0xe) on the bugtracker are still welcome to bump the bugs filed.


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - Milhouse - 2016-05-17

(2016-05-17, 15:25)diddle Wrote: Don't know the LE guide lines here... but why not simply wait until severe show stoppers are fixed before adopting a new kernel (instead of always being on the bleeding edge)?

These are bleeding-edge builds, which is often a double-edged sword. In most cases a new kernel will fix existing bugs, and even make new hardware usable that wasn't previously usable (Skylake, whatever). If we don't plough on and use the latest kernel we'll have all those people with the latest unusable hardware complaining because they're excluded. Not to mention finding these bugs early is the best way to getting them fixed upstream (in theory, anyway...).

When should we switch to a new kernel? Who is to say when it is ready without widespread testing? Should we always be a major kernel release or two behind, which would mean we would only now be switching to 4.4 or possibly 4.5... so much for bleeding edge. Smile

Unfortunately in this case, 4.6 has turned out to be a bit of a dog - whose fault that is I don't know, probably Intel's as non-Intel gear seems fine with 4.6. Hopefully 4.7 will be an improvement. I suspect 4.6 might be fairly short-lived.


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - walkerx - 2016-05-17

(2016-05-15, 22:37)fritsch Wrote:
(2016-05-15, 20:32)walkerx Wrote: It's not disabled - on the menu screens it is set as enabled

quick video showing what happens and confirmation that VAAPI enabled

http://sendvid.com/nqu01uux

Then you have Deinterlaced forced to On and chosen "Deinterlace" method, which will bypass gpu post processing, copy all the stuff to memory and deinterlace in there. That makes only sense for interlaced content. This setting should never be set to "On".

done some further testing - if i set the de-interlace to no then this particular movie starts to play but then get green screen in between frames - i will try to backup as mp4 and see what happens


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - john.cord - 2016-05-17

(2016-05-17, 15:51)Roby77 Wrote: or you can use 0509x that use old 4.4.7 kernel

http://milhouse.libreelec.tv/builds/testing/Generic/

nope that has issues as well... tried it.


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - Roby77 - 2016-05-17

really strange no issue for me on braswell n3150 in 8 day testing...

funny


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - melon2112 - 2016-05-17

(2016-05-16, 06:47)fritsch Wrote:
(2016-05-16, 04:00)Milhouse Wrote:
(2016-05-16, 03:33)melon2112 Wrote: Sorry...I was thinking it was just a simple fix. I did a debug...click here

I went through a few other builds...#420 works...I think that was the last one that worked. This is a debug log from #420 Click Here

Any advice would be much appreciated.

No obvious audio-related error that I can see (but fritsch knows more about this than I do, so might see something I've missed). What I would suggest is temporarily renaming /storage/.kodi and testing a "clean" Kodi and #0515 without your addons (some of which are known to cause problems) and default settings/skin.

Boot up again and post the output of: xrandr --verbose please.

It's a kernel bug, which changed the default code to enable radeon's audio. I hope the fix goes to rc8 / final.

In all cases: File a bug report with bugs.freedesktop.org drm/radeon section


Here is xrandr output Click Here

I also did it for #420...Click Here

I will now go post on freedesktop...

Thanks for the help


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - fritsch - 2016-05-17

Quote: output_csc: bypass
supported: bypass, tvrgb, ycbcr601, ycbcr709
audio: auto
supported: off, on, auto

^^ they are nice, the output_csc modes. Most likely proper "Limited Range" output is possible. You can try to force audio to on and choose the @@@ device in kodi.

Force enabling audio is done with: xrandr --output HDMI-1 --set audio on

Any reason you run on HDMI-1? and not HDMI-0? Same issure there?


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - Milhouse - 2016-05-17

New LibreELEC.tv Krypton build #0517: Generic
(Supercedes previous build)

Code:
# uname -a
Linux LibreELEC 4.6.0 #1 SMP Tue May 17 21:41:35 BST 2016 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160517213927-#0517-gdab8bd8 [Build #0517]

Based on tip of LibreELEC.tv master (dab8bd82, changelog) and tip of XBMC master (7d1fff68, changelog) with the following modifications: Build Highlights:
  1. NOTE: DVD playback remains temporarily disabled
  2. New 4.6.0 kernel
  3. libnfs pagecache
Build Details:
  1. LibreELEC.tv:
    • linux: update to linux-4.6 (PR:357, 1 commit, 26 files changed)
  2. XBMC:
    • [cmake/win32] Build addon libraries (PR:9820, 1 commit, 2 files changed)
    • [network] improvements to the webserver implementation (PR:9576, 7 commits, 20 files changed)
  3. libnfs:
    • Pagecache v2 (PR:146, 3 commits, 6 files changed)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] patch: Disable -werror as libnfs won't build 32-bit without it



RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - Roby77 - 2016-05-18

does anyone want to be a guinea pig and test it for bsw ? :p

my waf, and son patience is finished for this month Big Grin


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - _Spook_ - 2016-05-18

4.6.0 final kernel is fine on SkyLake


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - melon2112 - 2016-05-18

(2016-05-17, 22:54)fritsch Wrote:
Quote: output_csc: bypass
supported: bypass, tvrgb, ycbcr601, ycbcr709
audio: auto
supported: off, on, auto

^^ they are nice, the output_csc modes. Most likely proper "Limited Range" output is possible. You can try to force audio to on and choose the @@@ device in kodi.

Force enabling audio is done with: xrandr --output HDMI-1 --set audio on

Any reason you run on HDMI-1? and not HDMI-0? Same issure there?

Unfortunately a no-go... It switches to audio being on after running it and checking but still no sound... Click Here

I tried going back to Kodi and manipulate settings there for sound and then tried changing refresh rates... Nothing worked.

As for why Hdmi 1...hdmi 0 must be the dvi port as there is only one hdmi port on the box.

Again thanks for any help on this.


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - smitopher - 2016-05-18

Build 0517

display freezes within 2 minutes

Logs:
##############################################
# LibreELEC #
# http://libreelec.tv #
##############################################

LibreELEC (community) Version: devel-20160517213927-#0517-gdab8bd8
LibreELEC git: dab8bd82361eb5dc1e1aece68f21c6fef441adfe
media-center:~ # dmesg | pastebinit
http://sprunge.us/eGaH
media-center:~ # journalctl -a | pastebinit
http://sprunge.us/WUJO
media-center:~ # cat /storage/.kodi/temp/kodi.log | pastebinit
http://sprunge.us/QSLh
media-center:~ # vainfo | pastebinit
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/va/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
http://sprunge.us/iNfQ
media-center:~ #


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - smitopher - 2016-05-18

(2016-05-18, 01:03)_Spook_ Wrote: 4.6.0 final kernel is fine on SkyLake
Can't say the same for Braswell

My Pentium NUC can't go more than a couple of minutes without locking up


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - smitopher - 2016-05-18

LE 7.0 runs pretty much fine.

Recent Millhouse LE builds can't run at all.

I surmise that this is due to Linux kernel issues with the Braswell CPU, of which needs to be fixed upstream of LE.

@fritsch, you suggest adding my logs to an open desktop issue?

[ 91.334025] [drm] stuck on bsd ring
[ 91.340486] [drm] GPU HANG: ecode 8:2:0xfffffffe, in VideoPlayer [743], reason: Ring hung, action: reset
[ 91.340489] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[ 91.340491] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[ 91.340493] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[ 91.340495] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[ 91.340497] [drm] GPU crash dump saved to /sys/class/drm/card0/error

Does the gpu dump get included in the logs I posted?


RE: LibreELEC Testbuilds for x86 (Kodi 17.0) - melon2112 - 2016-05-18

(2016-05-18, 01:16)melon2112 Wrote:
(2016-05-17, 22:54)fritsch Wrote:
Quote: output_csc: bypass
supported: bypass, tvrgb, ycbcr601, ycbcr709
audio: auto
supported: off, on, auto

^^ they are nice, the output_csc modes. Most likely proper "Limited Range" output is possible. You can try to force audio to on and choose the @@@ device in kodi.

Force enabling audio is done with: xrandr --output HDMI-1 --set audio on

Any reason you run on HDMI-1? and not HDMI-0? Same issure there?

Unfortunately a no-go... It switches to audio being on after running it and checking but still no sound... Click Here

I tried going back to Kodi and manipulate settings there for sound and then tried changing refresh rates... Nothing worked.

As for why Hdmi 1...hdmi 0 must be the dvi port as there is only one hdmi port on the box.

Again thanks for any help on this.

We'll I tried #517 just for kicks to see and the new kernel fixed it. I now have sound

Thanks for all the help and suggestions.