Posts by chewitt

The "wetek-hub" image is for installing to eMMC storage. It works for most, but for others (with the possible issue of dry solder joints on the board) it sees keyboard input during early boot causing it to enter the u-boot console and unless you have the UART cable connected this creates the impression of a bricked device. I couldn't figure out the issue so the only option was to discontinue that image. However, if Android is still installed to the device you need to use the AMLGX "box" image anyway so that's not a major problem. Have a read here: https://wiki.libreelec.tv/hardware/amlogic - AMLGX is not perfect but for basic H264/HEVC media over a local connection it works well enough and you're using latest Kodi and add-ons.

RPi5 is a good choice and the 4GB board is more than enough for LE use (2GB would be fine, but doesn't exist). As long as the NAS and RPi5 are both connected to a Gigabit Ethernet switch the connection should be fast enough.

I'd guess a combination of filsystem formatting options used (defaults are not always the optimum for e.g. big disks) plus inherent differences between filesystem types. It's impossible to know without getting hands-on with the actual drive.

Quote from Free Man

Just have to reconfigure everything. Sigh. Shrug. The price of living on the bleedin' edge, I guess...

There are two types of computer user: those who are religious about taking backups, and those who didn't lose all their data yet.

The LE settings add-on has a backup function. Explore it.

IR remote does not require device-tree changes: https://wiki.libreelec.tv/configuration/…ration-advanced

https://github.com/chewitt/linux/…oot/dts/amlogic <= The only device with VFD support in LE at the current time is the Tanix TX3. You'll find the commits that add that VFD support in the same amlogic-6.9.y branch. You will also find examples of me adding new device-tree files (e.g. p271 board) in that branch; creating a new .dts file is mostly a copy/paste exercise, then use "git format-patch" to export diff patches to the LE build-system and build your own AMLGX image that includes the Linux kernel patch(es) using these instructions: https://wiki.libreelec.tv/development/build-basics . I wouldn't guarantee the VFD config for the TX3 will be the same as your no-name box, but there is documentation for the driver among the commits too.

IMHO, if the x96-air device-tree works, just use that and if the BOOT text bothers you put black electrical tape over the VFD. It will save you a large amount of time and effort.

dd if=/dev/mmcblk1 | gzip > of=backup.img.gz

You can pipe the dd output through gunzip ^ to reduce the size of the backup file (empty space compresses well) but I would avoid using dd to make backups because you still need to read all the empty space and it will take ages. It's faster and more portable to backup the content in the filesystem than to the backup entire filesystem.

The backup function in the LE settings add-on captures /storage/.cache, /storage/.config and /storage/.kodi, which covers all the main content on the card and normally produces a 0.5-2GB sized tar file. The restore function in the LE settings add-on will make the process of recovering from backup simple too. If you need to include more directories; learn how to use create a .tar file with the files and directories you need inside (there are thousands of HOWTO docs in Google).

Create and test/boot a different SD card to prove the hardware is okay. If it boots, the issue is (was) the SD card.

Can you post the sample file somewhere so we can have a look at it?

If you flashed a bad ROM to the box breaking u-boot, LE isn't going to boot on the device. If you didn't break u-boot, you can see if any of the "meson-sm1" device-tree files work with the AMLGX "box" image. You can create your own device tree by copying the relevant bits from existing ones in the kernel to create a new one, and then either compiling the kernel or exporting a patch to the LE buildsystem to include it with an image. If that all sounds like rocket-science; stick to looking for Android ROM images (which is not anything we can help with).

Or just build your own LE image with the extra driver included https://wiki.libreelec.tv/development/build-basics

powerarmour An obvious question: Is this media something you ripped, or is it "test media" that you downloaded from the Internet? .. because 9/10 "test" files are designed to stress/break decoders to find bugs. TL/DR; use real media not test media.

vaughng Allwinner H6 does not support hardware AV1 decoding so ffmpeg will fall back to software decode, and as AV1 is mostly used on large sized 4K media/streams the CPU will choke on the task.

It looks like the soundbar capabilities aren't being exposed to the RPi5 through EDID data on the HDMI connection. The debug log clearly shows only FL/FR speakers are available; hence Kodi is downmixing 6.0 media to 2.0 to match the advertised layout. If pass-through is used, the stream is not decoded (for downmix) and magic on the TV side results in the soundbar working.

I'd be looking into TV settings for eARC? options to ensure the Soundbar EDID is presented to the RPi5, then things should work. If nothing exists the workaround might be to temporarily connect the RPi5 directly to the soundbar, run "edid create" to capture the EDID data, then reconnect the RPi5 to the TV again. On reboot the RPi5 will see the cached Soundbar data not the live TV data.

Comparing 11.0.3...11.0.4 · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

The Kodi package is updated several times between those two releases; the before/after tags/githashes are:

-PKG_VERSION="20.2-Nexus"
-PKG_SHA256="4e81abf81172812bc8891f69a7a80a2b846298cecaae7b5009725e28a3040c23"
+PKG_VERSION="1497cc889e52558258739405bca536167f626cc2"
+PKG_SHA256="38ea7898c088bd266426dd7e545a92cac5307d94a2406258232c60e73297f7d3"

Compare the contents of guisettings.xml under the two different skins and see if there are differences.

These days you can probably handle ext4 things under WSL, but NTFS dates from '90's era MS which was more aggressively against the idea of allowing use of anything other than the one true OS to rule them all..

Start with sharing a Kodi debug log with several plays that demonstrate the scenarios (with an explanation).

powerarmour read and implement a mode whitelist: https://wiki.libreelec.tv/configuration/4k-hdr .. then share a clean log.

The source Da Flex linked is outdated and won't compile for the Linux 6.6 kernels we use in LE12. This one is more up-to-date and should be fine: https://github.com/lwfinger/rtl8852bu. It's not something we will entertain adding to the main LE image, as we have a long-running policy of refusing to add more Realtek vendor drivers.