The written style of your posts is hard to follow; too much "conversation" and not enough facts, and lots of broken text and missing punctuation. NB: We are used to reading Google translated copy/pasted text. You are welcome to post the original German text to your posts (in addition to the English translation). If you want to post only in German perhaps post in the kodinerds forum.
Posts by chewitt
-
-
I'll keep an eye on the progress of Rockchip and the TV boxes based on that chip.
There are currently no device-tree files for modern-ish Rockchip based Android set-top boxes in the upstream kernel, and after years of slog attempting support for Android boxes on Amlogic hardware the project staff have no real interest or plans to repeat that experience on Rockchip hardware. In short, even if support for current/recent Rockchip SoC(s) becomes brilliant, you should have low expectations of finding an LE image for the box.
-
I'm a firm believer in "if it works, don't fix it" so if all is good there is no burning need to update frequently. That said, with a nightly build things like add-ons are in a development repo, so at some future point when Kodi moves from Alpha to Beta to release that dev repo will initially stop being updated, and later will be nuked to free up disk space; so once things move to release it's probably a good idea to bump. Other users have OCD about running the latest nightly, but while we are generally pretty good at avoiding any bugs and problems, these are nightlies so everyone runs them at their own risk.
-
-
I run LE from an nvme drive on an RPi5 and it works fine. Just boot the RPi from SD card, write the LE image to the nvme drive using dd, then set the boot config changes needed, power off and remove the SD card, power on again.
-
The "format not supported" screen idea is simple, but the implementation logic is non-trivial once you start to think it through; feel free to have a crack at the problem.
-
ConnMan and IWD are simple packages to bump up/down normally. I can't remember bumping iw which probably indicates it's no drama too. There are nightlies here https://test.libreelec.tv/12.2/RPi/RPi2/ if you want to narrow things down by date.
-
LE12.2 and LE13 codebases should be using the same kernel/firmware and connman/iwd versions.
-
Start with building a standard image. Then (outside the LE buildsystem) clone ConnMan sources, and make/commit your changes to the files. Then create diff patches of your changes (git format-patch) and move the patch files to packages/network/connman/patches and rebuild the image; the presence of patches will be detected and the buildsystem will rebuild connman (only) and package a fresh image. Transfer the .tar or .img.gz file to /storage/.update/ on the RPi and reboot to update.
-
RK3288/RK3328/RK3399 depend on a different kernel patchset which I am still trying to encourage (re)work on from knaerzche and Kwiboo. I'm not really able to judge the state of things and I don't have working test hardware. I'm not suprised there are issues, and I don't plan to do much about it for now.
RK356X is expected to have issues with page faults as there's been zero development on fixing buffer sizes. As I don't really code, I plan to have Claude AI investigate that problem, but first I need to prepare all the relevant source materials for the prompt, and then I'll need to have enough tokens/time to let it work on the issue. AV1 isn't supported on the hardware.
-
It's not uncommon to find Android u-boot firmware that hardcodes the same MAC for all devices, so LE normally (re)creates a new MAC from the CPU serial which is guaranteed to be unique.
-
AFAIK that's been fixed (worked-around) in RPi kernel code.
-
Most S905W boxes have SDIO WiFi chips like SSV6501P that aren't supported in the mainline kernel. Drivers can be found for the 3.14 and 4.9 Amlogic (Android) vendor kernel, but they don't compile against the mainline kernel due to major crypto differences that were made in mainline several years ago. One of the Armbian devs did manage to evolve/fixup the SSV6501P driver enough to work on Rockchip boards, but he nuked Amlogic support in the driver in the process, and it doesn't work that great on Rockchip so AFAIK nobody has bothered to reinstate Amlogic support. Even if it was done I'd refuse to include that driver in LE images as the driver code looks like it was authored by a first-year computer science student (and that's being rude to students); it's garbage.
Look at https://wiki.libreelec.tv/configuration/…ration-advanced for IR remote things.
-
Bash
#!/bin/sh # SPDX-License-Identifier: GPL-2.0-or-later # Copyright (C) 2009-2016 Stephan Raue ([email protected]) # Copyright (C) 2017-present Team LibreELEC (https://libreelec.tv) token=$(echo "LibreELEC-9.2" | sha256sum | cut -d ' ' -f 1) cat "$@" | curl https://paste.libreelec.tv -F 'file=@-' -H "Authorization: Bearer ${token}"Save that ^ as /storage/newpaste and make it executable with chmod +x /storage/newpaste
Then do pastekodi -c | /storage/newpaste and it will generate the URL
ix.io has been down for years, hence we use our own paste server these days.
-
You can interrupt boot to enter the u-boot console and set things in the u-boot environment (env) if you ave a USB debug UART tool connected, but I don't think that will get you anywhere as I'm not sure mainline u-boot supports that kind of GPIO power-on control on Amlogic hardwar; the mainline codebase is rather minimal and focussed on not much beyond booting the board. I'd suggest asking Q's in the Armbian forums as their devs are more up on this kind of topic, and while LE is a little different to Armbian, they are also using upstream u-boot not the downstream vendor sources that CE are using.
-
Banned add-ons are present, no support.
-
Use full path to the binary, e.g. /usr/bin/connmanctl not just connmanctl as the bash script doesn't have knowledge of $PATH from the bash interpreter, unlike the console which does.
-
The gold standard for support is currently still an RPi5 board; not the fanciest specification but definitely the most reliable. Rockchip is making strong progress though and is now ahead on media codec support. Some audio issues need to be resolved for RK3588 to steal the crown from RPi5, and support for the trickle-down derivatives and slightly older RK hardware that share capabilities with the RK3588 chipset also need some attention.
