Posts by chewitt

[provider_wireguard]
Type = WireGuard
Name = AirVPN
Host = 213.152.162.12
WireGuard.Address = 10.173.72.95/32
WireGuard.ListenPort = 1637
WireGuard.PrivateKey = REDACTED
WireGuard.PublicKey = REDACTED
WireGuard.PresharedKey = REDACTED
WireGuard.DNS = 10.128.0.1
WireGuard.AllowedIPs = 0.0.0.0/0
WireGuard.EndpointPort = 1637
WireGuard.PersistentKeepalive = 15

See if this ^ works. Host is the WireGuard server that you connect to, so you need to resolve nl3.vpn.airdns.org to an IP (not possible to use an FQDN with ConnMan) and WireGuard.Address is the IP allocated to you, and since you are not connecting to access an internal subnet I'm making an educated guess that this should be /32 not /24.

Quote from Free Man

Because, of course, if a tornado hits my house, the most important thing is to get Kodi back up and running ASAP!

Damn right

Quote from Cellblock1

I flashed a TWRP zip and now when I try to boot into recovery nothing happens!

You are not installing LibreELEC. Please post the question in a forum for Android users.

It plays on all the devices I have to hand, none of which has an H6 chip. I need to rummage in cupboard to find one..

It's faster, but the impact is I/O not compute or GPU performance so boot is marginally faster and scrolling around the GUI where art is being read/rendered is marginally faster. It's "marginal gains" and FOMO territory .. it's not so much faster that you're really missing out.

Yes, the AMLGX box image. It's so long since I booted a Hub with Android still installed that I can't recall the exact process, but either it will work with a simple SD card swap, or worst case you might need to invoke recovery boot by holding down the recovery button that's visible through the case holes (on the underside of the case), powering on (plug the cable in) then releasing the button after a couple of seconds.

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.