Posts by smf007

    There has been a continual up and down over the last couple years with regard to the reboot issue.

    If you try a google, there is a back and forth breakage between the Kernel and u-boot. General summary seems to be related to the power for attached devices, e.g. SD-Card, USB, EMMC, so what you have attached also seems to impact whether you are impacted or not. Even just changing the speed of SD-Card has an impact.


    For any of the Libreelec team, the following might be of some help if you hadn't already seen:

    Armbian - meson64: edge: rework to kernel 5.19 which with regard to the reboot issue just references

    This discussion of CONFIG_DRM_MESON=m vs. CONFIG_DRM_MESON=y in terms of a broadly acceptable solution.

    Armbian's later update to Kernel 6.0.13 continued to follow suit on CONFIG_DRM_MESON=y

    Armbian - Update kernel configs for Meson64 CURRENT / EDGE

    Using the latest Generic-Legacy nightlies, there are missing library dependencies for the music visualization plugins. Seems to be a case of the plugins being compiled for Generic (GBM) instead of Generic-Legacy (X11). Below is for shadertoy, but the others are similar.

    I had cleaned out any archived copies in the packages folder, so I don't think it got a previously cached copies of the plugins.

    Code
    ldd: $warning: you do not have execution permission for `./visualization.shadertoy.so.20.3.0'
            linux-vdso.so.1 => linux-vdso.so.1 (0x00007fff70fa6000)
            libGLESv2.so.2 => not found
            libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff15b05b000)
            libm.so.6 => /usr/lib/libm.so.6 (0x00007ff15af7e000)
            libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007ff15af5e000)
            libc.so.6 => /usr/lib/libc.so.6 (0x00007ff15ad9e000)
            /usr/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff15b2dc000)

    I have gotten it working. Hopefully the following would provide assistance to anyone else encountering the problem.

    I was setup using the main lirc configuration file, Lircd.conf. As a test, I switched to using the distributed toml keymap file (see /usr/lib/udev/rc_keymaps/*). To do so, remove the lircd.conf and create a file ~/.config/.rc_maps.cfg containing:

    * * hauppauge.toml

    So follow these instructions instead of the Lirc documentation.

    I'm using an IR remote that is using the Hauppauge codes (PVR-250). Both a Hauppauge remote as well as a Harmony universal programmed as Hauppauge. The IR receiver being the built-in Odroid C2 one, so meson-ir.

    The lirc.conf for the remote is the borg standard Hauppauge from the lirc website.

    ir-keytable -t shows only one scan code per key. I also note that it immediately responds for each keypress, there is no waiting for the second keypress.

    Using the nightlies on an Arm - Odroid C2, there is an issue for my remote following the upgrade to Lirc 0.10.2.

    In short, Lirc 0.10.2 does not issue commands on each keypress. Instead, the key presses appear to be queued, with the queue being translated to commands on every 2nd key press. For example:

    1. Press down button - No effect on Kodi
    2. Press right button - Kodi responds with a down action (and navigation sound) followed by a right action (and navigation sound).

    In terms of the nightlies:

    Between those two builds is Pull lirc: update to 0.10.2 #6966

    The Kodi debug log does not help since it only records when it receives the commands from Lirc, which is after the issue.

    vpeter thanks. With the rebuild of the binary plugins, everything is good now.

    I will note though that generic-legacy is required due to the dependencies on X11. GBM is missing the libraries so Kodi will just sit with the spinner spinning, no recognition that the libraries didn't load unless you check a debug log. For GBM, the missing are:

    libXext.so.6 => not found

    libX11.so.6 => not found

    libxcb.so.1 => not found

    Thanks.

    The builds versus hash in order of commit history are:

    Build dateHash
    20220720 (works)3a4dc81
    20220723 (broken)0da8a26
    20220723 (broken)0008ab5

    In order of commit, the Pulls covering that range are:

    3a4dc81 Pull #6717

    1182c1a Pull #6721

    13bb8f3 Pull #6724

    06fd018 Pull #6715

    2cc0585 Pull #6726

    771b9b9 Pull #6470

    f529cc9 Pull #6727

    0da8a26 Pull #6729

    0008ab5 Pull #6730

    None of them are obvious as to breakage. If you were able to build Libreelec yourself, I would probably start by looking at #6727 as that appears to have triggered issues for others as well.

    daniel235 so it worked fine with 2022 June 08 build of b78941a?

    If that build worked fine, then the question would be if pull #6673 caused the problem. That was merged 2022 July 08. So try something just after that. Something like

    https://test.libreelec.tv/11.0/RPi/RPi4/LibreELEC-RPi4.arm-11.0-nightly-20220709-6050346.img.gz

    Then to confirm that pull is the issue, try the build just before

    https://test.libreelec.tv/11.0/RPi/RPi4/LibreELEC-RPi4.arm-11.0-nightly-20220707-379df42.img.gz

    If it is that pull, then it will need to be dissected some as there are a number of changes included in it, library and Kodi changes.

    When trying to play a physical bluray disc using nightlies (x64)(nightly-20221114-9c34b63 11.0), they aren't working.

    Debug log

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    This is a disc that has worked on this system previously using much older Libreelec versions.

    chewitt, issue is if one wants to disable the service. It can't be disabled as the symbolic link, from the "WantedBy" dependency, can never be deleted due to the file system being read only.

    When ServiceA has a "WantedBy" ServiceB, a symbolic link is created under ServiceB that results in ServiceA being run. When using systemd to disabled ServiceA, systemd would delete the symbolic link.

    In this case our filesystem is read only, so systemd cannot delete the symbolic link under kodi.target, thus the ledfix service can never really be disabled as kodi.target is always running it.

    Hi chewitt.

    I was just trying to disable ledfix.service on my C2 when I discovered that service is disabled already, yet it still is being run at boot. It seems ledfix.service currently has an error in that it lists kodi.target as both a "Wants" as well as a "WantedBy". Likely the "WantedBy" should be dropped.

    I take that back. Seems the issue is purely that when having a "WantedBy", systemd would be creating (enable) or removing (disable) a symbolic link under the wantedby target, but that fails since the filesystem in read-only.

    Hi chewitt.

    I was just trying to disable ledfix.service on my C2 when I discovered that service is disabled already, yet it still is being run at boot. It seems ledfix.service currently has an error in that it lists kodi.target as both a "Wants" as well as a "WantedBy". Likely the "WantedBy" should be dropped.

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    That runs through a few blurays. Last two are BD+, the BD+ is detected, the BD+ library is found, but it ends up flagged as BD+ not handled.

    ...hum....seems I got the same issue here.

    Maybe we can finazlize the thread by solvng the issue. My current logfile can be accessed here:

    http://ix.io/2AUH

    Sorry to bump such an old thread, but I do agree with this being a problem with 9.2 specifically for BP+ discs. The logfile that The_SMU posted though is not a debug log.

    Below is a portion of what I captured on my system showing the failure in bdplus_init().

    I haven't checked if this was corrected in 10, but that would be the next step is to confirm if this is still a problem with the latest.