[riccardo]

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.

[Milhouse]

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

[Milhouse]

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.

[Milhouse]

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

SHA256 Checksum: 6001aa4dde8c2d3627dba6a3381f4c8bb9509e91a49a5c22c0e66c47429c7a52 (Generic)

text:
# 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:

• Includes latest kodi-platform master (e8574b8)
  
• Includes latest libcec master (d57d3ac)
  
• Includes latest libnfs master (6dfc87d, ahead +10)
  
• Includes latest p8-platform master (1eb12b1, ahead +1)
  
• Includes latest addons: inputstream.adaptive (df0dbd3, +15), inputstream.rtmp (ce7f559), peripheral.joystick (2008fdc, +1), peripheral.xarcade (f09a0e7), pvr.argustv (609a2e7, +2), pvr.demo (964686d), pvr.dvblink (47cbff0, +2), pvr.dvbviewer (2369d9e, +9), pvr.filmon (f736ab4, +2), pvr.hdhomerun (a9d7309, +1), pvr.hts (f4ea60f, +2), pvr.iptvsimple (90a8d6f, +1), pvr.mediaportal.tvserver (e4a9dae, +2), pvr.mythtv (d53d4b8, +24), pvr.nextpvr (7e36106, +2), pvr.njoy (4467cac, +1), pvr.octonet (203f800), pvr.pctv (e28a90f, +2), pvr.stalker (a99ad5e, +2), pvr.teleboy (bdbd6b2, +3), pvr.vbox (6ed2f63, +2), pvr.vdr.vnsi (cbb75ab, +3), pvr.vuplus (d77458b, +2), pvr.wmc (fd89178, +3), pvr.zattoo (8ddb060, +7), vfs.libarchive (6d39012), vfs.sftp (6749200)
  
• Include [env] compare (perma): kodi: next
  
• Include [env] compare (perma): TESTING: increase timeout to ensure OS is able to create core dump/crash log
  
• Include [env] patch: RPi/RPi2: enable Broadcom WiFi debugging (see details)
  
• Include [env] patch: kodi: use upstream repo for Milhouse RPi builds
  
• Include [env] patch: kodi: remove annoying, excessively repetitive addon logging
  
• Include [env] patch: HACK: Disable multiple PVR addons during migration. Always enable inputstream.* and os.*
  
• Include [env] patch: rev hack for kodi
  
• Include [env] patch: Bump included addon versions to prevent online updates
  
• Include [env] patch: Add experimental splash video for RPi
  
• Include [env] patch: Add kodi binary addons (pvr, adsp, inputstream, vfs, peripheral.joystick/xarcade, other)
  
• Include [env] PR:3084 (perma): linux (RPi/Generic): update to linux-4.19.2
  
• Include [env] PR:3089 (perma): iptables: update to iptables-1.8.2
  

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
     

[whocarez1]

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.

[riccardo]

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.

[whysoserious]

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.

[Milhouse]

Weekly Linux 4.20-rc3 build #1118x: Generic

Known issues:

text:


iptables temporarily replaced with nftables due to build issues

xf86-video-nvidia may not be working (or show garbage characters)

[Milhouse]

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.

[Milhouse]

 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...

[whocarez1]

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.

text:


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

[Milhouse]

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).

text:


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).

[Matt Devo]

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.

text:


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

[Matt Devo]

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

[whocarez1]

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 But then again, I have not reinstalled Libreelec completely for many months, I just use the update function for the time being.