Note that in LE13 the timezone setting is removed from Kodi and is now configured in the LE settings add-on.
Posts by chewitt
-
-
Please look at the sent log. Maybe, after all, it will be possible to find the reason?
You will receive no support in this forum while banned add-ons are installed.
-
Is there a plan in the future to support the latest versions of Kodi (21.3)?
No plans. Kodi removed support for amcodec in 2018 to focus on non-proprietary decoding methods and community efforts to hack support back in to current Kodi versions are now focussed on newer Amlogic kernels that do not support older Amlogic hardware.
-
ChatGPT analysed the splats and suggested the change, but GoogleAI claims the CPU is 'Sea Islands' and not 'Southern Islands' and according to https://wiki.archlinux.org/title/AMDGPU this needs a different config. This would explain why it doesn't appear to have switched drivers.
So see if changing to radeon.cik_support=0 amdgpu.cik_support=1 makes a difference? - I would also disable SMB component debug logging as this only adds to system load. Also experiment with 'start/stop' option for adjust-refresh, as this is a little less aggressive at syncing. This article is not just for 4K/HDR and has suggestions https://wiki.libreelec.tv/configuration/4k-hdr
-
It's possible there's some fallout from this change: https://github.com/LibreELEC/Libr…dad6c4cf3d49647
Can you put Kodi in debug mode and attempt to change the data and then "pastekodi" and share the log (URL) so we can see if there's an obvious error message (might be, might not be).
-
Any way to force LibreElec to use db version 139?
You cannot force, but you can downgrade to an older nightly that still uses the same DB version. Note that you will then need to drop the newer tables from the database else when you later bump to a newer version the tables already exist and the migration process will not be (re)triggered.
-
I made PR as https://github.com/LibreELEC/LibreELEC.tv/pull/10960 .. please close this PR.
Thanks, I'll close when Radxa respond to the upstream plans question in https://github.com/radxa-pkg/aic8800/issues/71
-
Some ChatGPT analysis of the kernel splats in the log suggests Kodi triggers a GPU driver bug. It also claims there are long-running issues with the (newer) radeon driver on old(er) hardware. It does also suggest disabling HW decoding to see if that code-patch is involved. And from your comment, it appears it is. I have no real knowledge of AMD hardware but it suggests seeing if the older amdgpu driver works better than radeon? .. which is achieved by adding the above ^ to the kernel boot params in the EFI boot config (as you are EFI booting and not using Syslinux). You can edit that from SSH by doing mount -o remount,rw /flash and then editing the file, then rebooting. If it doesn't work out things might crash or not display but you should still be able to SSH back in and revert the change made.
-
LE10 to LE12.x requires you to navigate the Python3 change in Kodi so deleting all (Python2) add-ons before update mitigates issues with them crashing and causing problems on post-update restart before Kodi has been able to download newer (Python3) versions. Add-on settings remain intact so normally all you need to do is reinstall add-ons from repos again. The Estuary Mod v2 skin seems to be available (under a new maintainer) https://forum.kodi.tv/showthread.php?tid=366400. The rest of the OS should update fine and you do not have an nVidia GPU so there is no need to run the Generic-Legacy image.
-
I don't create Pull requests for AIC8800 driver because I agree with chewitt and LibreELEC perspective.
Yasai-san Just create a pull-request with "This PR is being submitted so information on how to add the AIC8800 driver package into a self-built image is more easily found. I support the project's wish to not add downstream drivers that have no visibility of being upstreamed and do not expect this to be merged" .. so we look less authoritarian when we close it without merging

-
It is not impossible to create/build mainline u-boot for eMMC install on Android TV box hardware, but this requires the original BL2 (and BL301) sources for the specific hardware (tweaked by the manufacturer for the out-of-spec low-bin RAM chips used in specific batches of boxes) which you don't have. It is also not impossible to reverse engineer boot firmware to extract the pre-compiled bits, but this requires the original Android ROM which you don't have. That task also requires tools/skills most users lack, and a level of repetitive "puling your teeth out" time and effort of that project staff have learned to avoid, and this is why none of the distros that you mentioned are interested in supporting eMMC install on Android boxes; except in a few rare cases where the original sources are available and the outcome is reliable.
You might have greater success in sourceing ROM images or find a more willing audience in Android supporting forums.
-
The Allwinner image supports overlays so you can probably just drop the existing dtbo file onto the SD card and modify the extlinux.conf to use it; LE and Armbian should be similar in how that’s done as they both use mainline u-boot.
Or you need to compile an LE image with a kernel patch to add the overlay so it will be compiled and added to the image. Or you submit the patch to our GitHub repository so it’s merged and added to the image; although we mostly refuse patches that are not also submitted to kernel mailing lists (we want to know the patch is good and will be dropped in the future when the fix is upstream).
-
-
Running the Kodi GUI at 4K resolutions (as per the other issue thread) probably doesn't help the GUI responsiveness. I wouldn't be suprised if running things at 1080p improves the remote situation?
-
The Linux end of things is probably trying to use a 4K mode the TV doesn't like. Append video=HDMI-A-1:1920x1080M@60D to the line of boot params in cmdline.txt on the SD card and reboot. That forces the intial DRM state to 1080@60 which should avoid the issue, and you want to be using 1080p for the Kodi desktop anyway (unless you want a slow GUI experience).
-
The lack of info in kodi.log proves Kodi didn't do/signal anything so the issue is either something in the Linux kernel/DRM layer or perhaps (as suggested) something related to the TV itself.
Is there anything in the system log (dmesg)?
-
Manufacturers who make hardware constantly add features to "improve" output, both to improve the viewing experience, but also to ensure the marketing department has something to support claims of their device giving the best experience. Some viewers claim these features do improve their experience and <insert_name_of_latest_device> is the best thing invented since sliced bread. Others seek to watch movies "as the director intended" and claim the same features detract from the experience. Reddit provides a free service to fuel all sides of the "what device/distro/player-app/settings works best" debate by selling advertising placement to the marketing departments of manufacturers and retailers.
IMHO dedicated BR/DVD/SACD/CD hardware usually gives the best result. However my kids destroy BR/DVD disks by leaving them wrong-side-down on the floor and never place watched things in the correct box, so I still rip everything and accept the lossy format conversion to mitigate those problems. I use general purpose settings when ripping. I do occasionally re-rip with tweaked settings if the results aren't so great. I still choose to watch certain films on proper hardware sometimes. The amount of 4K/UHD media that I purchase and rip vs. stream from a subscription service (media reformatted to suit streaming and look okay on more devices) or record from a broadcast (media reformatted to squeeze into broadcast constraints) continues to decline though.
-
Two comments:
a) It's not unheard of for Android boxes to hard-code CPU identifiers in their software so that less scrupulous manufacturers can pass off older or cheaper SoC chips for something more expensive, or even chips from a completely different SoC vendor, if that helps to sell more boxes and/or clear stock. Hence you might find different SoC chips being reported in different places. The best way to check what's physically inside the box is to open it and literally see what's under the heatsink (if one is present). NB: Even that's not infallible, as we've also seen chips silk-screen reprinted to hide what they are, but that's not common.
b) There is currently a single LE image for an RK3328 based Android box, the "a1" image. If this works, great. If not, there are no plans to add more images for Android set-top boxes. As a general rule, trying to support them is a challenge. Boxes are typically based on reference designs so there is enough in-common to easily boot an image, but booting is no guarantee of reliability and there is enough variation in designs (combined with selection of cheap low-bin components) to ensure reliability always remains slightly beyond reach; whether that's due to electrical or thermal or other reasons.