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) - riccardo - 2018-11-18

Hi, please how to disable a message appearing when LE starts saying "Remote communication server failed to start" ?
And I don't know if it's my config or a bug but audio passthrough has still some issues on NUC 6CAYH. The Dolby+ audio plays only if I play the video containng this audio as a first video (after fresh boot). If I first play a video with other audio format in it and then try to play other one with Dolby+, the audio won't play. I have to reboot LE to get Dolby+ working again.
Edit: If this happens, the LE gets messed up and all the non-HD audio formats won't play either. Only DTS-HD/MA and TrueHD stay functional.


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

(2018-11-18, 14:45)whocarez1 Wrote: Just tell me what else might be needed, or what else to test, and I will do it later today.

You have the same kernel errors as the other users have reported - I would suggest posting information on the kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=201517


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

(2018-11-18, 18:22)riccardo Wrote: Hi, please how to disable a message appearing when LE starts saying "Remote communication server failed to start" ?
And I don't know if it's my config or a bug but audio passthrough has still some issues on NUC 6CAYH. The Dolby+ audio plays only if I play the video containng this audio as a first video (after fresh boot). If I first play a video with other audio format in it and then try to play other one with Dolby+, the audio won't play. I have to reboot LE to get Dolby+ working again.
Edit: If this happens, the LE gets messed up and all the non-HD audio formats won't play either. Only DTS-HD/MA and TrueHD stay functional.

No log, no problem.


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

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

SHA256 Checksum: 6001aa4dde8c2d3627dba6a3381f4c8bb9509e91a49a5c22c0e66c47429c7a52 (Generic)

# uname -a
Linux NUC 4.19.2 #1 SMP Sun Nov 18 21:11:41 GMT 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20181118210231-#1118-gd35701a [Build #1118]

# Kodi version
(18.0-RC1 Git:4b7d471). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (d35701a, changelog) and tip of XBMC master (4b7d471, changelog) with the following modifications: Build Highlights:
  1. iptables: update to iptables-1.8.2
  2. [skinning] Bump GUI API after many changes since last bump
Build Details:
  1. LibreELEC.tv:
    • mesa: update to mesa-18.2.5 (PR:3108, 1 commit, 1 file changed)
    • xf86-video-nvidia: update to xf86-video-nvidia-410.78 (PR:3107, 1 commit, 2 files changed)
  2. XBMC:
    • [fix] remove outdated JsonSchemaBuilder executable after #14774 (PR:14899, 2 commits, 1 file changed)
    • [addons] Switch from TVDB to TMDB as default TV show scraper (PR:14898, 2 commits, 84 files changed)
    • [skinning] Bump GUI API after many changes since last bump (PR:14896, 2 commits, 3 files changed)
    • [addons] sync with repo (PR:14897, 1 commit, 2 files changed)
    • Actually destroy window system on application shutdown (PR:14901, 1 commit, 2 files changed)
    • [Estuary] Rip audio-cd from 'Disc' home menu entry (PR:14903, 1 commit, 2 files changed)
  3. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:3089 (perma): iptables: update to iptables-1.8.2



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - whocarez1 - 2018-11-19

I suppose we can assume that the PCIe error is the cause, and not something else. It seems to be related to the PCI bridge and the errors appear frequently when the network is in use. And yes, indeed the device connected to 00:1c.0 seems to be the ethernet controller. I guess trying a couple of kernel options might be a workaround too. But it is probably better to follow it up with a bug report.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - riccardo - 2018-11-19

(2018-11-18, 18:22)riccardo Wrote: Hi, please how to disable a message appearing when LE starts saying "Remote communication server failed to start" ?
And I don't know if it's my config or a bug but audio passthrough has still some issues on NUC 6CAYH. The Dolby+ audio plays only if I play the video containng this audio as a first video (after fresh boot). If I first play a video with other audio format in it and then try to play other one with Dolby+, the audio won't play. I have to reboot LE to get Dolby+ working again.
Edit: If this happens, the LE gets messed up and all the non-HD audio formats won't play either. Only DTS-HD/MA and TrueHD stay functional.
 Here is the log:
http://ix.io/1swC
The Dolby+ audio issue appears at 22:14:25.803 T:140377956149376
Previous file with DTSHDMA7.1 played fine
The "Remote comm. server failed to start" message issue happend as well. I just don't recognize it in the log.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - whysoserious - 2018-11-19

(2018-11-18, 18:22)riccardo Wrote: Hi, please how to disable a message appearing when LE starts saying "Remote communication server failed to start" ?
Somewhere in your network settings (I forget where exactly, I think it's in the LibreELEC program add-on) is the option to tell LibreELEC to wait for a network connection before starting up. Set it for 10 sec. just to be sure.


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

Weekly Linux 4.20-rc3 build #1118x: Generic

Known issues:

iptables temporarily replaced with nftables due to build issues
xf86-video-nvidia may not be working (or show garbage characters)



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

(2018-11-19, 00:16)whocarez1 Wrote: I suppose we can assume that the PCIe error is the cause, and not something else. It seems to be related to the PCI bridge and the errors appear frequently when the network is in use. And yes, indeed the device connected to 00:1c.0 seems to be the ethernet controller. I guess trying a couple of kernel options might be a workaround too. But it is probably better to follow it up with a bug report.

Please add your kernel logs to the existing bug. It may be worth pointing out on the bug that this problem started with 4.19-rc1.


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

(2018-11-19, 00:33)riccardo Wrote:  Here is the log:
http://ix.io/1swC
The Dolby+ audio issue appears at 22:14:25.803 T:140377956149376
Previous file with DTSHDMA7.1 played fine
The "Remote comm. server failed to start" message issue happend as well. I just don't recognize it in the log.

Try adding the "wait for network" setting - your WiFi network IP address is being assigned as Kodi is starting which will cause problems for Kodi when it tries to access your network.

As for the audio issues, a debug log (wiki) provides more useful information and is what we mean by a "log" around here...


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - whocarez1 - 2018-11-19

Yes, I will do that. However, there are at least two of those "AER: error corrected" bugs reported recently for kernel 4.19. I am not sure if each of those bugs are triggered by the same thing. This one is about the same PCIe port: https://bugzilla.kernel.org/show_bug.cgi?id=199695 As a small workaround I added pci=nomsi to the kernel command line. It "helps" for the time being, at least on my Chromebox. Surely just a workaround, since it only suppresses a possible driver problem.


mount -o remount,rw /flash
vi /flash/EFI/BOOT/syslinux.cfg
reboot

If you do not boot through EFI, possibly just edit /flash/syslinux.cfg


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

(2018-11-19, 00:54)whocarez1 Wrote: Yes, I will do that. However, there are at least two of those "AER: error corrected" bugs reported recently for kernel 4.19. I am not sure if each of those bugs are triggered by the same thing. This one is about the same PCIe port: https://bugzilla.kernel.org/show_bug.cgi?id=199695 As a small workaround I added pci=nomsi to the kernel command line. It "helps" for the time being, at least on my Chromebox. Surely just a workaround, since it only suppresses a possible driver problem.

Yes, I've found bugs which mention type=Physical Layer (same as the bug you linked above), and then there are bugs with type=Data Link Layer, which matches the errors reported in this thread and also the bug I linked previously. I'm not sure if the type actually matters to be honest - they could be the same bug (or same root), or completely different bugs.

Also, I'm not sure what the commonality is of this bug - it doesn't affect everyone, but seems to affect Chromebox, which is based on r8169, although I don't see this issue with my Revo 3700 which is also r8169 based. However the errors are being kicked out by the PCI Bridge, and the details in the bug I linked seem to have come from an AMD Threadripper system.

All we know is that this seems to have started with 4.19-rc1. It could be a configuration issue, but PCIEAER (PCI Express Advanced Error Reporting) related configs are the same in both 4.18.14 and 4.19-rc1.

I don't want to be the middle man in this bug as I can't reproduce it so can't add much value, in which case posting your logs direct to the bug is the best option right now - if there are any fixes proposed I'll be more than happy to help you all test them (I've cc'd myself on the bug).

(2018-11-19, 00:54)whocarez1 Wrote:

mount -o remount,rw /flash
vi /flash/EFI/BOOT/syslinux.cfg
reboot

If you do not boot through EFI, possibly just edit /flash/syslinux.cfg
If you are booting with EFI you should only need to edit /flash/syslinux.cfg - we have done away with /flash/EFI/BOOT/syslinux.cfg (several months ago).


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Matt Devo - 2018-11-19

(2018-11-19, 00:54)whocarez1 Wrote: Yes, I will do that. However, there are at least two of those "AER: error corrected" bugs reported recently for kernel 4.19. I am not sure if each of those bugs are triggered by the same thing. This one is about the same PCIe port: https://bugzilla.kernel.org/show_bug.cgi?id=199695 As a small workaround I added pci=nomsi to the kernel command line. It "helps" for the time being, at least on my Chromebox. Surely just a workaround, since it only suppresses a possible driver problem.


mount -o remount,rw /flash
vi /flash/EFI/BOOT/syslinux.cfg
reboot

If you do not boot through EFI, possibly just edit /flash/syslinux.cfg
 as a corollary, the issue isn't AER or the lack of support thereof; disabling AER and rebuilding the firmware will eliminate the error messages, but not fix the performance issue.  Disabling MSI via kernel parameter fixes the performance issue, so that would seem to be where the issue lies.  I'll dig a little further


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Matt Devo - 2018-11-19

(2018-11-19, 02:14)Milhouse Wrote: Also, I'm not sure what the commonality is of this bug - it doesn't affect everyone, but seems to affect Chromebox, which is based on r8169, although I don't see this issue with my Revo 3700 which is also r8169 based. However the errors are being kicked out by the PCI Bridge, and the details in the bug I linked seem to have come from an AMD Threadripper system.
 
I have 3 Chromeboxes here with the r8169 - a Haswell, a Broadwell, and a Kabylake. The Haswell box is completely crippled by this bug, xfer rates are <250KB/s. The Broadwell box is affected but less so - I get ~3MB/s with that. I haven't tested the Kabylake box to get precise figures, but it seems minimally affected, if at all, by kernel 4.19.x based on daily use (and the kernel log shows no AER errors). The HSW/BDW boxes get > 50MB/s transfer with either a 4.18.x kernel or pci=nomsi used with 4.19-rc1+

edit: the KBL box sees a drop from ~50MB/s (likely limited by write speed to USB boot media) to ~35MB/s on 4.19.x


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - whocarez1 - 2018-11-20

(2018-11-19, 02:14)Milhouse Wrote: If you do not boot through EFI, possibly just edit /flash/syslinux.cfg
If you are booting with EFI you should only need to edit /flash/syslinux.cfg - we have done away with /flash/EFI/BOOT/syslinux.cfg (several months ago). 

Interesting. On my system editing /flash/syslinux.cfg had no effect Smile But then again, I have not reinstalled Libreelec completely for many months, I just use the update function for the time being.