Posts by chewitt

    S905L is an S905X without VP9 support, 10/100 Ethernet, no BT, and faked 2GHz CPU (all GXL boards are 1.5GHz). There is no direct support in the upstream kernel but differences from S905X are minor so creating a custom device-tree shouldn't be hard; I started to look at changes for the Venz V10 - though that user disappeared so progress stalled. NB: The current hardware decode drivers assume all GXL boards support VP9 so attempting VP9 media playback will result in blank screens in Kodi.

    P201 is a GXBB (S905) device-tree; hence it will not boot a GXL (S905X) derived device. SSV6200 is a newer variant of the SSV6051 chip and also not supported. The SSV vendor drivers are horrific quality (achieving new depths of bad) and do not compile against an upstream kernel, only the vendor kernels. No support means no support.

    If you can provide me with the Android dtb file and dmesg boot log, and a working remote control config, I can look at adding support.

    The second partition on the SD card is designed to self-resize on first-boot so there is no need to "fix" this non-problem. Just create an SD from the box image and set the dtb name in uEnv.ini .. and that's all to do. As per the Amlogic page in the wiki; do not rename dtb files to dtb.img; do not change the location of files.

    When DRM Prime is enabled I can't skip the video for more than 10sec without the picture freezing. Sometimes pressing the ESC button brings back the menu but it also happens that I have to reboot. When DRM prime is disabled skipping is no problem but the video is kinda choppy - not really smooth.

    I assume the codec used is HEVC and thus the clearly written statements about the imperfect state of HEVC seeking that are in release notes are accurate. If the codec is H264 seeking works well (at least in my own testing). One of the upstream kernel static analysis tools recently flagged a memory leak in the HEVC codec and a fix for this will be in LE 11.0.1. That might help prevent resource starvation in some scenarios (stop/escape back to the GUI is more likely to work) but HEVC seeking itself needs development effort, and there are currently no volunteers for the task so you shouldn't expect progress anytime soon. If you disable DRMPRIME content is software decoded, but most 1080p HEVC is a little beyond the CPU capabilities of an S905 board. The Pi Foundation devs are currently working on some changes that might result in a more efficient software decode path that might improve that, but fixing the hardware decoder (needing volunteers) would be preferred.

    External Content www.youtube.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.

    Download the update to /storate/.update and rename /storage/.kodi out of the way then reboot to update. You'll end up with a clean install but can easily copy/move things back to where they need to be. Or if that sounds like gibberish, start over with a proper clean install.

    Code
    2023-03-16 15:31:48.335 T:140209459025664 WARNING: Attempt to use invalid handle 535
    2023-03-16 15:31:50.581 T:140208469178112 WARNING: Attempt to use invalid handle 541
    2023-03-16 15:31:52.427 T:140209459025664 WARNING: Attempt to use invalid handle 545
    2023-03-16 15:31:59.165 T:140208469178112 WARNING: Attempt to use invalid handle 558
    2023-03-16 15:32:04.821 T:140209459025664 WARNING: Attempt to use invalid handle 571
    2023-03-16 15:32:06.693 T:140209467418368   ERROR: GetDirectory - Error getting
    2023-03-16 15:32:06.693 T:140209459025664 WARNING: Attempt to use invalid handle 576

    ^ this is in the Kodi log.

    Code
    Mar 16 15:32:07 LibreELECmini kernel: EXT4-fs (sda1): error count since last fsck: 1
    Mar 16 15:32:07 LibreELECmini kernel: EXT4-fs (sda1): initial error at time 1676930944: ext4_check_bdev_write_error:217
    Mar 16 15:32:07 LibreELECmini kernel: EXT4-fs (sda1): last error at time 1676930944: ext4_check_bdev_write_error:217

    ^ this is in the kernel log. In my experience this sort of error message points to disk corruption, and with SSDs the main reason for that is cell errors (integrity problems in the memory chips) from a drive that's starting to fail.

    Sample clips so we can repeat the issue (or prove it's something local to your device) are useful. Pictures of artefacts aren't useful. I suspect it's something unusual about the media because stats show a stable and increasing number of C2 boards running the image and while I've deliberately tried to set people's expectations low since there are missing things and it's not perfect, I'm surprised (and pleased) at the overall lack of user issues being reported.