Posts by milhouse

  • Libreelec 8&9 Kernel regression (VAAPI)

    I tested my latest build, #1004 (based on kernel 4.13.4) with your test file streamed over smb:// and didn't have a problem while using a NUC6i5SYH.

    Can you try disabling MPEG-2 VAAPI hardware acceleration as below, and see if that helps you?

    I have MPEG-2 VAAPI enabled, and it works fine - no freeze - but there's obviously a problem with your system/configuration so this might allow you to work around it.

    Looking at your dmesg, LHCL, there's a GPU hang being reported. Unfortunately that could be anything - a kernel bug, or (more likely) an Intel driver bug.

    If you wish to raise a bug, please follow the guidelines here, in section "1.1 DRM Kernel" - add "drm.debug=0x1e log_buf_len=2M" on your kernel command line, reproduce the bug, then open a bug report and attach all of the files documented in the "DRM Kernel" section.

  • LE 8.0.2 hangs (or restarts) when left on PVR screen.

    Your PSU should be fine, just wanted to be sure - bcmstat.sh will report any irregular events with the "y" option.

    Quote from jahutchi

    => Not sure whether this also points at PERIPHERALS::CPeripheralAddon::ProcessEvents as being the cause?

    No, it's a different cause this time (Kodi 17 is an almost completely different code base, though).

    The lirc error shouldn't be related, but it is odd - is that with #0928b as I'm pretty sure that build is using lirc 0.10.0 not 0.9.4d. Try disabling lirc in LibreELEC Settings addon.

  • LE 8.0.2 hangs (or restarts) when left on PVR screen.

    So I don't think it's an OOM, at least not initially - what I think may be happening is that it's a regular Kodi crash (for some reason) but due to the other stuff you have running (Docker, tvheadend etc.) there isn't enough free RAM for the system to process the core dump, and consequently the system locks up. Now that you've shut down Docker etc., the core dump can be processed and Kodi restarted without the system freezing. Adding 128MB of swap may help you process the crash dump in these extreme situations when running Docker etc., as might reducing the GPU memory to 256 so that there is 128MB more free RAM for the CPU.

    So what is causing Kodi to crash? That's not entirely clear... you've posted three crashlogs:

    #1 FMPT

    #2 CdYB

    #3 EOLJ

    #2 and #3 both show the same reason for the crash, a problem with PERIPHERALS::CPeripheralAddon::ProcessEvents so this may be one for garbear.

    #1 just seems like a random memory error, possibly due to insufficient power (you're not overclocked, so we can rule that out). If you run "bcmstat.sh ZDA d 30 y" do you see any entries in the "UFT" column before, during or after Kodi crashes? If so, please post them.

  • Edimax AC1200 MU-MIMO USB2.0 Adapter (rtl8812bu)

    Yeah.... unfortunately Edimax have sold you the hardware and now told you to fix it yourself.

    Ultimately this is a Realtek issue, but Edimax hiding behind a "fix it yourself" argument isn't helping you as the consumer, and it doesn't help Edimax either in the long term.

    What Realtek must do (and Edimax need to be telling Realtek this, too) is push their driver to the main kernel tree. See this post explaining the benefits *for everyone* when drivers are maintained in the kernel tree.

    Many Realtek drivers now resemble abandonware as they no longer receive updates from Realtek and are now supported with varying degrees of success by the open source community, usually only to allow them to build with the latest kernels. The driver Edimax pointed you to is no different as it will not build with kernels newer than 4.11.0 - the fixes are available but being ignored which is a classic example of another abandoned driver. Note that the 4.11.y kernel is already obsolete and end of line, so it's not unreasonable to want a driver that builds with the most recent mainline kernel which is 4.13.y (and used by LibreELEC).

    Obviously if the driver had been pushed to the main kernel tree then it would now be maintained "for free" and we wouldn't have these issues, or even this conversation.

    So yeah, unfortunately we will not be adding yet another out-of-tree (and most likely already abandoned) Realtek driver into LibreELEC. It really is time Realtek pulled their finger out and did things right. I know this doesn't help you, but long term this is the only sane option.

  • LE 8.0.2 hangs (or restarts) when left on PVR screen.

    Quote from jahutchi

    As far as I'm aware I don't have anything unusual running at 9pm.

    Yes, it's entirely possible that the timing is random.

    Quote from jahutchi

    This is a fairly minimal build with just a handful of add-ons. I'd be happy to wipe it clean to a vanilla install with only the pvr.hts addon installed and re-test if that would help..... since I have a backup of all my key folders (.config / .kodi etc)

    Just shutdown kodi, rename /storage/.kodi to /storage/.kodi.bak and restart LibreELEC then you will have a "clean" system with no additional addons enabled - this should be enough to test, and you can restore your original installation (if you wish) by deleting .kodi and then renaming .kodi.bak to .kodi.

    PVR HTS has been implicated in OOM crashes but a definite cause is yet to be identified.

    Seeing all the GPU memory returned strongly suggests Kodi is shutting down, or crashing. This is definitely abnormal behaviour so testing a "clean" system would be a start, and then introduce add-ons one at a time until the problem can be reproduced (the last add-on in theory being the cause of the problem).

    Perhaps in addition to running bcmstat.sh, logging running processes might yield some additional information - run the following in a second ssh window:

    Code
    while [ : ]; do ps -opid,ppid,pgid,user,nice,vsz,rss,stat,time,etime,args > /storage/ps.log; sync; sleep 30; done

    then upload /storage/ps.log after the system has frozen and been restarted.

  • LE 8.0.2 hangs (or restarts) when left on PVR screen.

    The entry at 21:00:25 is interesting, as that shows all of the GPU and ARM memory being freed which would normally only happen when kodi.bin is exited, ie. when Kodi has been shut down. So whatever is subsequently using all of the ARM RAM, it's probably NOT Kodi as that is no longer running (or maybe it has crashed, but I wouldn't expect a crashing kodi.bin to use all of the ARM RAM so that seems unlikely).

    What else is installed on your system, that would be terminating kodi.bin at 9pm? This may explain why the system appears "frozen" as Kodi is no longer running, however if the device no longer responds to ping or ssh then the system may still be struggling due to the OOM situation.

    Based on the time when you posted, and the timings in your log, I'm guessing the system has already been frozen for several hours, in which case pulling the plug is probably the only option.

  • LE 8.0.2 hangs (or restarts) when left on PVR screen.

    Yes, that's definitely a memory leak, or at least there's a process that is using far, far too much memory. The out of memory (OOM) process killer should eventually kill whatever process is consuming all of the memory (be it kodi.bin, or some other process) and then the system should return to normal however it can take some time (10s of minutes, maybe an hour or two) for the OOM to trigger depending on the amount of RAM that is left available (and it might not trigger at all if there is just enough free RAM to prevent OOM from triggering).

    If you can leave the system alone for a few hours then, assuming it comes back to life, can you upload the contents of "journalctl -a | pastebin" as this would confirm which process caused the OOM.

    Do you have any idea what process or activity is scheduled to run at 9pm? It would be interesting to know if the timing is consistent, as that might give a clue as to what process/activity is running.

  • Intel NUC Apollo Lake / Kaby Lake hdmi passthrough patch

    Quote from fRzzy

    is there any unofficial build(s) that has this patched applied?

    No, the patches are not in official builds because in their current form they cause more problems than they solve with the 4.11.12 kernel used in the latest official build. It's something that will be looked at again in 8.2.1 but the patches will not be in 8.2.0.

    Quote from fRzzy

    I made a mistake to purchase the NUC6CAYH and now it's unusable :(

    "Unusable" is a little bit of an exaggeration.

  • Can't enable cifs shares in v8.1.2

    Quote from soder

    What's can that be? Someone that can help me?

    /Söder

    Please start a separate thread for your buffering issue rather than hijacking this one which is specifically about CIFS mounting issues (which you've already solved). Don't forget to include your debug log. Have you considered upgrading the outdated and insecure OpenELEC you use for your fileserver?

  • LE 8.0.2 hangs (or restarts) when left on PVR screen.

    I've uploaded a new debug-enabled build #0928b: RPi2

    This includes a deadlock fix for PVR database accesses, the latest version of which appears to be getting positive results so it might be worth testing with this build in case it is related.

    Otherwise, I'd supsect a memory leak... you could confirm this by running "bcmstat.sh ZDAd 30" in a ssh console, then leave it running until the crash/hang occurs. If memory has been leaked then the "Memory Free" column will be close to zero, and the "Mem kB" columns (which reflect delta and accumulated ARM allocations respectively) will be consistently negative, indicating repeated memory allocations (ie. leakage - positive values are reported whenever a "free" occurs).

  • Migrated From windows

    Based on your log it looks like your HDMI connection to the Marantz AVR has no audio channels:

    Code
    m_channels        : NULL

    But aside from that, your log is full of Kodi Audio Engine errors.

    There's something about your hardware setup/configuration that Kodi really, really, doesn't like.