Either the configuration expects files to be in a standard location and you've put them somewhere else, or you configure the location in the add-on (which I don't use or have any experience with) but some kind of unhandled issue with paths or formatting or permissions prevents the files from being read. As generic advice; don't use paths with spaces, ensure the text files have unix line endings (not Windows) and ensure the certs have 600 perms not 644/755/777.
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.comContent 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.
-
Just make a backup of the 10.x install in-case you want/need to revert, and then update the existing install. No need to wipe it unless you have a good reason to.
-
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.
-
LE is very-much using in-tree (upstream kernel) drivers and not out-of-tree (vendor) drivers.
-
Use an HDMI audio break-out box to extract stereo audio for RCA outputs; or perhaps S/PDIF if the Amp has a digital input.
-
-
Enable "adjust refresh" (start/stop) and "refresh rate doubling" then configure the whitelist for 1080p @ 60/59.94/50/24/23.976 modes.
-
i tried these both repo in android side kodi20 and they are working.
but in this le11 build giving error.
Official:Forum rules/Banned add-ons - Official Kodi Wiki
I think it's brilliant when pirate shitware doesn't run on our OS. No further support.
-
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.
CodeMar 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.
-
Do we have to blindly guess at the problem, or are you giong to provide a full debug logfile?
-
The pass file probably needs "chmod 600" perms to skip that warning (but it's only a warning not an error). The other errors are fatal and it clearly doesn't see the files or there's something like a space in the filename or path.
-
The AMLGX "box" image has "meson-gxm-mecool-kiii-pro.dtb" .. but do not rename it to dtb.img as the AMLGX boot process is different. You can read more on that here: https://wiki.libreelec.tv/hardware/amlogic
-
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.
-
The error you posted suggests you're running the wrong Generic image (as stated already). As for the external grabber; no idea. I have never used Hyperion and have no interest in it. I'm just pointing out that GBM graphics does not support it at all.