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) - harryruhr - 2018-05-11

Can't install any addon

I just installed a Milhouse build for the first time. It seems that I can't install any Add-on. Log is at http://ix.io/1a3R

The log suggests there is a problem with DNS
 
Code:
18:46:17.479 T:139847253104384 ERROR: Requested path http://mirrors.kodi.tv/addons/krypton/plugin.video.youtube/plugin.video.youtube-5.5.1.zip not found in known repository directories
18:46:17.479 T:139847253104384 ERROR: CAddonInstallJob[plugin.video.youtube]: failed to resolve addon install source path

But when I ssh on the box and download it with "wget http://mirrors.kodi.tv/addons/krypton/plugin.video.youtube/plugin.video.youtube-5.5.1.zip" it downloads without problem. "ping mirrors.kodi.tv" is working as well.  DNS is working fine. I changed network settings from DHCP to manual but to no avail.
Like I said, this happens with any Add-On I tried so far.

Build is Generic (x86_64) 0508 (tried 0510 as well - same issue).

Hardware is a Mini-ITX Board from ASRock Model D1800B-ITX


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-05-11

(2018-05-11, 20:48)Nekromantik Wrote: From 0510 Kodi freezes when it does library clean on boot.
Tried 3 times all froze at different stages. 

Does not seem to create crash log.

Yes, thanks for the report - there are some issues related to threading which are causing a problem. The threading changes do fix another crash issue (or two, mostly CEvent:Set() that several users reported), so it's one step forward, one step backwards situation at the moment. Hopefully a fix tonight or tomorrow for the threading related crashes.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-05-11

(2018-05-11, 21:03)harryruhr Wrote: Can't install any addon

I just installed a Milhouse build for the first time. It seems that I can't install any Add-on. Log is at http://ix.io/1a3R

The log suggests there is a problem with DNS
 
Code:
18:46:17.479 T:139847253104384 ERROR: Requested path http://mirrors.kodi.tv/addons/krypton/plugin.video.youtube/plugin.video.youtube-5.5.1.zip not found in known repository directories
18:46:17.479 T:139847253104384 ERROR: CAddonInstallJob[plugin.video.youtube]: failed to resolve addon install source path

But when I ssh on the box and download it with "wget http://mirrors.kodi.tv/addons/krypton/plugin.video.youtube/plugin.video.youtube-5.5.1.zip" it downloads without problem. "ping mirrors.kodi.tv" is working as well.  DNS is working fine. I changed network settings from DHCP to manual but to no avail.
Like I said, this happens with any Add-On I tried so far.

Build is Generic (x86_64) 0508 (tried 0510 as well - same issue).

Hardware is a Mini-ITX Board from ASRock Model D1800B-ITX

That doesn't look like a DNS issue - the error suggests the addon doesn't exist in the repository that has been downloaded. One for the add-on system developers? Maybe there's a problem with the mirrors...


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - harryruhr - 2018-05-12

(2018-05-11, 22:14)Milhouse Wrote: That doesn't look like a DNS issue - the error suggests the addon doesn't exist in the repository that has been downloaded. One for the add-on system developers? Maybe there's a problem with the mirrors...

No, the add-on is definetely downloadable.

In the meantime I did go back as far as build 0415 - and there the installation of add-ons is working like a charm, so it has to be an issue with the recent builds. I also found a recent post of someone reporting the same problem at
https://discourse.osmc.tv/t/rpi-3-b-kodi-18-addons-do-not-install-from-repository/72623


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-05-12

(2018-05-12, 01:21)harryruhr Wrote:
(2018-05-11, 22:14)Milhouse Wrote: That doesn't look like a DNS issue - the error suggests the addon doesn't exist in the repository that has been downloaded. One for the add-on system developers? Maybe there's a problem with the mirrors...

No, the add-on is definetely downloadable.

In the meantime I did go back as far as build 0415 - and there the installation of add-ons is working like a charm, so it has to be an issue with the recent builds. I also found a recent post of someone reporting the same problem at
https://discourse.osmc.tv/t/rpi-3-b-kodi-18-addons-do-not-install-from-repository/72623

I'm not saying the add-on isn't available for download - I'm saying it appears that Kodi couldn't find the addon details in the repository (an xml file) that Kodi had downloaded. Maybe the repository details were briefly out of sync somehow.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - TheKraut - 2018-05-12

(2018-05-10, 10:23)seiichiro0185 Wrote:
(2018-05-09, 18:34)seiichiro0185 Wrote: Hi there,

first of all thanks for all the great work with this build and Kodi/Libreelec in general, which runs absolutely amazing on my "Production" Mediacenter (Old Zotax ZBox passive).

I recently got my hands on a NUC7PJYH and I'm seeing the same problem as TheKraut reported. The integrated IR-Receiver works for a couple of keypresses and then stops doing anything. This happens with all the Alpha Builds back until March (didn't test further), and also with a current ArchLinux Installation including latest Kernel 4.16.7. I also tried the Installation from my old Zotac Box and a completely clean new Install of Libreelec.

I'll try to get a Windows 10 Installation onto the device and report back if it behaves any different. 
 So I installed Windows 10 on my Intel NUC7PJYH and tested the integrated IR receiver there.  It works without a problem. So it really seems to be a software problem on Linux (I suspect in the kernel). Unfortunately I have no usefull experience with debugging kernel driver issues.

If anyone has an idea what I could test or do to debug this problem further I'll gladly do it.  
Hi @seiichiro0185, @HiassofT,

Thanks, seiichiro0185, for taking the time to test with Windows 10.

I'm still not fully convinced that this is a Linux only / kernel related issue though, for two reasons.

First, in the the discussion at the Intel Community, people described it as "hit and miss" for the 2017 NUC7s when running Windows. So, it may take a while to reproduce, but the general notion was that the issue was still there every now and then.
Second, things appear to work perfectly fine in the LE installer, which should be running the same kernel (or at least, parts of it), right? @seiichiro0185, maybe you could briefly validate this behavior?

Anyway, I decided to buy some cheapo $4 IR receiver now, which should arrive in late May. Hopefully, this will provide more insight into whether we are facing a more general IR problem with LE / the NUC7 here or not.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-05-12

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

SHA256 Checksum: 6326eef3b766fdd9e160745966479af6176fe20d471673f120c735fcf5b7299e (Generic)

# uname -a
Linux NUC 4.14.39 #1 SMP Sat May 12 03:49:14 BST 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20180512034606-#0511-gcf34178 [Build #0511]

# Kodi version
(18.0-ALPHA2 Git:eb1e22e). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (cf34178, changelog) and tip of XBMC master (dfd2eff, changelog) with the following modifications: Build Highlights:
  1. Generic: allow lower IR timeouts on ITE CIR devices
Build Details:
  1. LibreELEC.tv:
    • create_addon: jenkins specific quirks (PR:2693, 1 commit, 1 file changed)
    • qemu: update to 2.12.0 (PR:2677, 1 commit, 1 file changed)
    • make: Fix glob handling (#2681) (e0b6641)
    • meson: update to 0.46.0 (#2686) (1fe9017)
  2. XBMC:
    • Resolution: User current resolution - desktop might be something else (PR:13868, 1 commit, 1 file changed)
    • [guiinfo] Fix LISTITEM_PROPRTY for bool and integer properties. (PR:13875, 1 commit, 1 file changed)
    • [fix] handle favourites from Profile directory in FileManager (PR:13872, 1 commit, 1 file changed)
    • utils/Variant: use std::to_string() instead of std::ostringstream (PR:13870, 1 commit, 1 file changed)
    • LinuxRendererGLES: Fixed texture type for Mesa 18 compatibility (PR:13865, 1 commit, 1 file changed)
  3. inputstream.adaptive:
    • compile fix (const_iterator) (0bbbccb)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:2689 (perma): init: add sky42 enhancements/bug fixes
    • Updated: [env] PR:2692 (perma): RPi, Generic: fix erratic IR timeout behaviour on Topseed mceusb receiver 1784:0011
    • Added: [env] PR:2694 (perma): Generic: allow lower IR timeouts on ITE CIR devices



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - HiassofT - 2018-05-12

(2018-05-12, 09:03)TheKraut Wrote: Second, things appear to work perfectly fine in the LE installer, which should be running the same kernel (or at least, parts of it), right? @seiichiro0185, maybe you could briefly validate this behavior?
I'm wondering if it could maybe be some resource conflict (shared IRQ etc) and/or a side effect of some other driver (wlan, network, bluetooth, ....). Yes, it's a very long shot and wild guess but it's puzzling that the IR receiver works fine in the installer.

Could you post the output of "cat /proc/interrupts"?

It could also be worth a try to disable the out-of-tree broadcom wifi driver. Create a /storage/.config/modprobe.d/disable-wl.conf with the following content:
Code:
blacklist wl

Also try disabling ethernet, wifi and everything else that's not 100% essential (like power saving and wakeup settings) in the BIOS. If this changes IR behaviour we have some starting point where we could further try to narrow it down.

so long,

Hias


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - yol - 2018-05-12

(2018-05-11, 21:03)harryruhr Wrote: I just installed a Milhouse build for the first time. It seems that I can't install any Add-on. Log is at http://ix.io/1a3R

Force-update add-on list or wait 24 hours


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - TheKraut - 2018-05-12

(2018-05-12, 10:30)HiassofT Wrote:
(2018-05-12, 09:03)TheKraut Wrote: Second, things appear to work perfectly fine in the LE installer, which should be running the same kernel (or at least, parts of it), right? @seiichiro0185, maybe you could briefly validate this behavior?
I'm wondering if it could maybe be some resource conflict (shared IRQ etc) and/or a side effect of some other driver (wlan, network, bluetooth, ....). Yes, it's a very long shot and wild guess but it's puzzling that the IR receiver works fine in the installer.

Could you post the output of "cat /proc/interrupts"?

It could also be worth a try to disable the out-of-tree broadcom wifi driver. Create a /storage/.config/modprobe.d/disable-wl.conf with the following content:
Code:
blacklist wl

Also try disabling ethernet, wifi and everything else that's not 100% essential (like power saving and wakeup settings) in the BIOS. If this changes IR behaviour we have some starting point where we could further try to narrow it down.

so long,

Hias  
Hi Hias,

Here you go: IRQ log before and after disabling broadcom wifi

Tried disabling BT and WiFi in LE first -> no improvement

Afterwards, I additionally disabled BT, WiFi, LAN and any power / wake-up related settings I could find in BIOS (incl. CIR wake-up from S3/4/5; deep S4/5) -> no improvement


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - HiassofT - 2018-05-12

(2018-05-12, 11:26)TheKraut Wrote: Here you go: IRQ log before and after disabling broadcom wifi

Tried disabling BT and WiFi in LE first -> no improvement

Afterwards, I additionally disabled BT, WiFi, LAN and any power / wake-up related settings I could find in BIOS (incl. CIR wake-up from S3/4/5; deep S4/5) -> no improvement
Well, it was worth a shot - thanks for testing!

There's are two more things you could try to gather some more info:

Create a /storage/.config/modprobe.d/ite-cir-debug.conf file with the following contents, to enable debug logging
Code:
options ite-cir debug=2

When the remote stopped working ssh in and upload dmesg.

Then press a remote button again and check if you got new ite-cir lines in dmesg (just verify if the timestamp is newer than before) - if yes, upload this dmesg too.

The other thing is to watch the IRQ count(s) of the ite-cir receiver in /proc/interrupts. When you press a button either one of the two numbers after "11:" should count up. Easiest way to do that is via the following command
Code:
watch -n 1 grep ite-cir /proc/interrupts

My guess is that for some (unknown) the kernel stops getting IRQs from ite-cir. So no new lines in dmesg and interrupt count doesn't go up anymore.

so long,

Hias


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - seiichiro0185 - 2018-05-12

(2018-05-12, 12:57)HiassofT Wrote: Well, it was worth a shot - thanks for testing!

There's are two more things you could try to gather some more info:

Create a /storage/.config/modprobe.d/ite-cir-debug.conf file with the following contents, to enable debug logging
Code:
options ite-cir debug=2

When the remote stopped working ssh in and upload dmesg.

Then press a remote button again and check if you got new ite-cir lines in dmesg (just verify if the timestamp is newer than before) - if yes, upload this dmesg too.

The other thing is to watch the IRQ count(s) of the ite-cir receiver in /proc/interrupts. When you press a button either one of the two numbers after "11:" should count up. Easiest way to do that is via the following command
Code:
watch -n 1 grep ite-cir /proc/interrupts

My guess is that for some (unknown) the kernel stops getting IRQs from ite-cir. So no new lines in dmesg and interrupt count doesn't go up anymore.

so long,

Hias  
Hi,
 
I just did the tests with the debug enabled, the dmesg is here: http://ix.io/1a7n (I did try to reload the driver at the end, with no result, also it seems the first part of dmesg from booting was already dropped). After the remote stopped working, there where no more messages.

Also the interrupt count stopped, as long as the remote  was working, the first number after the 11: did count up, when it stopped it stayed at the value:

Code:

11:       1471          0          0          0   IO-APIC   11-edge      ite-cir

So it seems your guess is right about the interrupts "getting lost" somewhere.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - TheKraut - 2018-05-12

(2018-05-12, 13:09)seiichiro0185 Wrote: Hi,
 
I just did the tests with the debug enabled, the dmesg is here: http://ix.io/1a7n (I did try to reload the driver at the end, with no result, also it seems the first part of dmesg from booting was already dropped). After the remote stopped working, there where no more messages.

Also the interrupt count stopped, as long as the remote  was working, the first number after the 11: did count up, when it stopped it stayed at the value:

Code:

11:       1471          0          0          0   IO-APIC   11-edge      ite-cir

So it seems your guess is right about the interrupts "getting lost" somewhere. 
Hi guys,

Here's another full dmesg log with cir debug enabled.

Don't mind the long pause at lines 755/756 - it was just me googling how to get a continuous log... Wink
 
Code:
while true; do dmesg -c >> dmesg.log;sleep 1; done



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - lanzorg - 2018-05-12

I just installed your latest build, I updated from stable LibreELEC Generic.

I can finally use VAAPI hardware decoding. Smile
But unfortunately I don't have working WiFi anymore.
It's a broadcom based chipset, it worked flawlessly with stable branch.
Is there a way to install/reinstall the WiFi driver?


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - HiassofT - 2018-05-12

@seiichiro0185 @TheKraut thanks, both of you, for your tests!

The thing I was interested in was the very few last dmesg log lines before the IR receiver stopped working, especially if ite_s_idle was called in the last IRQ block - which was not.

This means ite-cir was still in "normal" receive mode, expecting further data to arrive when suddenly IRQs stopped arriving.

So my guess is the ite-cir driver could probably be fine and the issue probably lies somewhere else. No idea where though, it could be anything - interrupt controller code, (management) BIOS, etc. Maybe it's some quirk in the ITE hardware that needs a workaround in the ite-cir driver, I wouldn't rule that out as well.

I'm out of clues now, but you collected some valuable info to better understand what's happening. Best do the same checks on Ubuntu/Arch and report that to the Ubuntu/Arch folks so they can pick up from there.

so long,

Hias