Posts by smf007

    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.