Posts by chewitt

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…6-6-hch@lst.de/ 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

<advancedsettings>
	<videoscreen>
		<monitor>Generic PnP Monitor #1</monitor>
	</videoscreen>
</advancedsettings>

^ that content goes in /storage/.kodi/userdata/advancedsettings.xml (from https://forum.kodi.tv/showthread.php?tid=363060) but I have no idea what to replace "Generic PnP Monitor #1" with. Perhaps "HDMI-A-1" or have a look in kodi.log for the m_deviceName and m_displayName values logged for audio cards as I have a hunch it'll be based on EDID data.

backup-wp2.img.gz

boot (AMLGX) from an SD card so emmc is not actively in use and write ^ that file with "emmctool w backup-wp2.img.gz" and you'll restore the factory image to the box. The backup is a raw (dd) image of mine before I first wiped it.

Ubuntu uses Grub, which will boot LE fine once you add entries for it.

Amlogic legacy images are using 64-bit (aarch64) kernels and 32-bit (arm) userspace for compatibility with 32-bit only libwidevine that's needed for Amazon, Netflix, etc. - and these days most containers are published only in x86_64 and arm64/aarch64 formats which aren't usable from 'arm' userspace. So you will need for find and pull 'arm' versions of the containers.

I'm not sure if adding "video=DP-1:1920x1080M@60" will result in DRM (and thus Kodi) preferring DP-1 output over HDMI-A-1 or will simply force that output to 1080p and not change anything. It's a cheap trick to try though.

rkershenbaum I've added a note to the wiki to highlight this point: https://wiki.libreelec.tv/configuration/wireguard

Quote from frankvw

Until ntfsfix is included again with LE using a Windoze box to clear the 'dirty' bit on the NTFS partitions is your only option, I'm afraid.

The ntfsfix utility has never been shipped with LE, and I've closed the pull-request that proposed adding it because it's an incomplete tool. From a support and data integrity perspective it's better to inconvenience users by forcing them to use the right tool (chkdsk.exe on Windows) than not-quite fixing the problems a filesystem has and risking data loss.

noggin thanks for confirming. I've sent the change to the LE repo for merging.

We have noticed that "noobs" images are not being built/published correctly .. it's being looked into.

I don't know the exact mechanics, but I suspect Zomboided's add-on is tracking the execution of add-ons and enables/disables the VPN as required. In that scenario the VPN is started and all traffic is being routed down the VPN tunnel. This is a little different from your use-case where you want to route traffic for specific add-ons over a different VLAN. You could conceivably do something similar to detect the add-on and change the default route, but this results in all traffic being routed over the second VLAN. The only way you can send traffic for a specific add-on (only that add-on) over the second VLAN is to use routing rules; but as noted that will be rather challenging to maintain due to the dynamic nature of how streaming services operate.

diff --git a/packages/network/bluez/package.mk b/packages/network/bluez/package.mk
index 9170f27418..0dd5ebef4d 100644
--- a/packages/network/bluez/package.mk
+++ b/packages/network/bluez/package.mk
@@ -62,6 +62,8 @@ post_makeinstall_target() {
         -e "s|^#\[Policy\]|\[Policy\]|g" \
         -e "s|^#AutoEnable.*|AutoEnable=true|g" \
         -e "s|^#JustWorksRepairing.*|JustWorksRepairing=always|g"
+    echo "[General]" > ${INSTALL}/etc/bluetooth/input.conf
+    echo "ClassicBondedOnly=false" >> ${INSTALL}/etc/bluetooth/input.conf
 
   mkdir -p ${INSTALL}/usr/share/services
     cp -P ${PKG_DIR}/default.d/*.conf ${INSTALL}/usr/share/services

noggin https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar contains ^ this patch based on information from https://github.com/bluez/bluez/issues/696 and https://github.com/bluez/bluez/is…ment-1854599254 which reads like the same issue.

Which LE release/version are you trying to install?