Posts by chewitt

H3N7R1K If you expected this experimental and developed-for-free (nobody charged you money) image to do anything more than boot (which might be pushing it on some hardware) you have rather inapropriate expectations. As the tone and language of your post were also not appropriate for the forum, it has been deleted.

The sequence would be: Stop container > Restart Docker > Start container .. not just restart Container or Docker. No ideas if that's the issue but I've seen similar things in the past (and admins restarting things in the wrong sequence resulting in no change).

Rockchip seem to be taking upstreaming more seriously again, but there's lots to do, the focus is mostly on the flagship RK3358 at the moment, and the media codecs are always left till last as they require the greatest effort.

Other than the need to remove/readd binary add-ons the arm > aarch64 change is low drama.

The A95X-F3 has an upstream device-tree file (authored by me) so the current AMLGX image is usable; with caveats that accompany G12A/B and SM1 boards (read the LE11.x release notes for the info, nothing changed). Read the Amlogic page in the wiki for install instructions: https://wiki.libreelec.tv/hardware/amlogic.

WiFi and BT won't work due to the MT7668 chip having no upstream drivers. The FireTV driver from the kernel mailing list Q&A is here: https://github.com/chewitt/MT7668 but I could never get it to compile in a usable form. Hence the repo is untouched and I archived it a while back to drop a hint to people that kept cloning the driver and asking how to compile it. I had a brief look at the ophub driver and that looks similarly bad to the one I found before. The guy that "figured it out" doesn't sound like he really figured it out either. I can't see an email for him, but his name is reasonably destinctive and Google shows the same name associated with some postings to kernel and freedesktop related things so he's probably traceable if you ask around.

I never looked into LED lights on those boxes either. The clock display might be do-able but for the light ring .. I'd need to see the original Android dts file or decompiled dtb to comment further.

The backup function in the LE settings add-on captures /storage/.cache, /storage/.config, and /storage/.kodi ONLY .. anything else that you put on /storage (including tar files in /storage/.update) will not be backed up. If you want more comprehensive backups; use the Kodi backup add-on or write your own backup script (and automate with cron or a systemd timer).

Yup, [email protected]/60 media is beyond CPU decoding unless having a very low bitrate. Up to 4K30 is normally fine though.

Quote from hadrien

Is it possible through the web interface to do that?

Not possible from the Kodi Web GUI. However, the LE12 add-on repo (I'm not sure about the LE11 repo) contains the "Web File Browser" add-on which provides a web browser GUI interface to the HPTC device where you can upload/manage files. However, this interface is intended for use over a LAN not the internet. If you expose it to the internet, expect security problems

Nightlies with the fix are on the test server now.

Are you trying to use IPSec?

I have a hunch you need to restart the Docker network; which requires you to restart Docker itself, not just the container.

The settings-addon check is based on what's currently runing, so if current = "arm" then it searches for compatible "arm" releases and doesn't find anything beyond the date we switched everything to "aarch64" .. so you'll need to do a manual update (wget the file from the server) and from that point forwards updates will work again.

You'll also need to uninstall/reinstall any binary add-ons; just keep/save the add-on settings when uninstalling and once they are reinstalled everything just works again.

In some ways RPi5 is a blunt instrument; throw CPU at the codec problem and make things work. However it has enough CPU to pull that off, and I've come to view this as a rather shrewd design decision. It normally takes man-years of effort to develop and maintain hardware codecs and RPi5 simply passes the buck to ffmpeg for software processing.

Quote from Rataplan626

Is that something I can do or help with?

Given your IT background, you can probably help

We (meaning you, as we don't have the hardware) need to bisect the kernel changes to find the breaking commit.

This explains bisecting: https://opensource.com/article/22/11/git-bisect

Clone the Linux kernel in a Linux VM and start bisecting; the known-good commit is "61fd484b2cf6bc8022e8e5ea6f693a9991740ac2" (Linux 6.1.38) and the known-bad commit is "d23900f974e0fb995b36ef47283a5aa74ca25f51" (Linux 6.1.55). Once started, the bisect process will then suggest a commit (githash) to test. You then mark this good/bad and it suggests another to test, and this process repeats until you find the breaking commit. The bisect process assumes you will build your own kernels. You will, but you need to do this within the LE build-system.

https://wiki.libreelec.tv/development/build-basics explains how to build an LE image; so create an Ubuntu 22.04 VM to build in and then checkout and build libreelec-11.0 branch (not the master branch) as this is more aligned to the Linux 6.1 kernel. The bisect workflow needs you to modify packages/linux/package.mk and change PKG_VERSION to use the githash that the bisect process suggested. Set PGK_SHA256 to nulll (PKG_SHA256S="") to skip checksum checks then re-run the LE image build command again. The buildsystem will detect that (only) the kernel package has changed and rebuild an LE image with the updated kernel package. Then transfer (scp is easiest) the latest .tar file from the target/ folder over to /storage/.update on your device and reboot to update and test that image.

If the card is detected correctly go back to the Linux kernel directory and mark that bisect point as good, and then it will suggest a new githash to test with. Repeat the edit/rebuild/test/mark process until bisecting identifies the breaking commit. Then tell us what that githash is, so we can email the kernel maintainers with information.

Hmm.. honestly no clue, but I'll sleep on it and see what that inspires (or not)

Looking at the kernel error messages in code; the "Unsupported Anysee version" is caused by a lack of front-end, so the actual error is from the tda10023_readreg function (the line above). However diffing between Linux 6.1.38 (11.0.3) and Linux 6.1.55 (from the kernel bug report) doesn't show changes to that driver other than https://patchwork.kernel.org/project/linux-…foundation.org/ which looks to be a legit bugfix. Perhaps revert that and https://lore.kernel.org/lkml/202307310…[email protected]/ and see if the original behaviour is restored. If yes, the fix isn't complete and something more is needed.

Ahh, I've forgotten that the 'w' option tries to resize etc. after the dd/writing stage; and all that will of course fail as emmc doesn't contain an LE image after restoring the backup. It doesn't cause any issues though.

Just flash the normal "LibreELEC*wetek-play2.img.gz" board file to an SD card and boot. Yes it technically still boots from emmc, but once u-boot on emmc finds extlinux.conf on the SD card and boots KERNEL/SYSTEM from the SD card, emmc is not actively used. Or at least the OS will not fault/lock-up when you overwrite emmc with the factory image.

You can also do "dd if=/dev/zero of=/dev/mmcblk1 bs=1m count=100" and erase the first 100MB of emmc which will trash u-boot and partition data. This will cause the box to lock up at some point, but on the next power cycle the box cannot boot from emmc and finds u-boot on SD card, then you copy the backup file over and write the file as mentioned before. This is technically better (emmc is definitely not being used in any way) but I never had issues with the first method.. so