Posts by chewitt

Quote from LybsterKodi

You now seem to be recommending a clean install and restore backup not cloning which is what I want to do

In my experience users fixate on "cloning" as the solution when there are easier and faster approaches. I'd guess that 75% of users seeking a cloning solution simply want to boot their system from a new card, and backing up the current install and restoring it to a clean install on the same LE version achieves this. The other 25% want to create a second LE instance with the same setup as the first, and the same backup and restore to same-version clean install achieves this too. True cloning is a pain in the rear as SD cards and USB sticks might have the same marketing size (128GB) but can have different sector counts due the nuances of manufacturing memory devices, which is a problem if making a bit-for-bit copy where the target device has a lower sector count (is smaller) than the source device. Cloning from smaller to larger devices doesn't have that problem so usually works fine.

https://pine64.com/product/rockpr…oth-5-0-module/ says this is a Cypress (aka Broadcom) CYW43455 SDIO module so the fix is probably to use the correct firwmare/nvram files for the module. If there is no board specific file provided the kernel driver will look for default files and use them, but the current ones we package are sourced from some Amlogic boards and might not give great results.

Pine64 probably have the correct brcmfmac43455-sdio.bin/brcmfmac43455-sdio.txt files to use in distro images and you can override the ones we provide by creating /storage/.config/firmware/brcm/brcmfmac43455-sdio.(bin/txt) locally and rebooting.

The GeForce 6100 is a firm no as it requires a "no longer supported" nVidia driver version that isn't compatible with the version of Xorg we use (for at least 4-5 years). Support probably stops around LE 8.0. I've no clue about the AMD card but if the Generic Legacy (Xorg) version doesn't work, it's likely a similar story. You can try older releases from https://archive.libreelec.tv/ but beyond a point you'll hit issues with TLS certificates and add-ons that aren't compatible.

NB: Someone's unused RPi3B will greatly outperform both cards and is likely better for the planet in electricity use terms.

risa2000 sent me a box to experiment with and I finally got around to fiddling with it

U-Boot 2024.01 (Mar 08 2024 - 08:27:47 +0000) minix-neo

Model: Minix Neo U9-H
SoC:   Amlogic Meson GXM (S912) Revision 22:a (82:2)
DRAM:  2 GiB
Core:  177 devices, 27 uclasses, devicetree: separate
MMC:   mmc@70000: 0, mmc@72000: 1, mmc@74000: 2
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
[BL31]: tee size: 0
[BL31]: tee size: 0
Net:   eth0: ethernet@c9410000
Hit any key to stop autoboot:  0 
Card did not respond to voltage select! : -110
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc2(part 0) is current device
Scanning mmc 2:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1:      LibreELEC
Retrieving file: /KERNEL
append: boot=LABEL=BOOT disk=LABEL=DISK quiet systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0
Retrieving file: /meson-gxm-minix-neo-u9h.dtb
## Booting kernel from Legacy Image at 08080000 ...
   Image Name:   
   Image Type:   AArch64 Linux Kernel Image (lzo compressed)
   Data Size:    12582235 Bytes = 12 MiB
   Load Address: 01c80000
   Entry Point:  01c80000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 08008000
   Booting using the fdt blob at 0x8008000
Working FDT set to 8008000
   Uncompressing Kernel Image
   Loading Device Tree to 000000007df30000, end 000000007df3d894 ... OK
Working FDT set to 7df30000

Starting kernel ...

It's not the most stable thing though .. so more experimenting needed.

SOURCE
|--- TVShowName
     |--- Series 01
          |--- TVShowName s01e01.mkv
          |--- TVShowName s01e02.mkv
     TVShowName s02e01.mkv
     TVShowName s02e02.mkv
     TVShowName s03e01.mkv

If you want to put files in Series/Season folders that's fine, but the files in the folder should follow the show name and should include sXXeXX or SXXEXX naming. It's not essential to put them in folders (some of mine are, others aren't) but again, the filenames need to be in the right format for things to scrape properly. You can even have both formats (as above) as long as there's no overlap in the filenames that you are using. My $0.02: keep names short/clean/simple and you avoid scraping issues.

NB: If you want to use random filenames, you need to provide local .nfo files that either map the random filenames to the online URL for the episode in an online scrapable source (IMDB, TVDB, etc.) or you need to provide all info in the local .nfo file and use the "local file" scraper not an online one.

If the goal is moving the RPi4 install from old to new SD card, take a backup in LE settings, clean install LE on the new card, then restore the backup. The backup only contains contents of /storage/.cache, /storage/.config, /storage/.kodi - If you aren't storing media on the SD card then a 16GB card is more than enough. If you are storing media use a USB>SD adapter to mount the old card once the backup is restored and copy media over to the new card. If no adapter, connect it to something else with a card reader and copy files over the network (it'll be slow, but you only do it once). NB: In nearly all cases copying/moving the content of the card will be faster than cloning tools as you only move e.g. 40GB of files on the card instead of copying 128GB of physical card.

FAT32 (vfat) partition can be any size but we use 512MB for default. The storage partition can be 100% remaning size. The system boots using the UUIDs of the partitions so labels can be anything you like (see cmdline.txt).

Read: https://wiki.libreelec.tv/configuration/…ration-advanced

The documentation is written for newer LE11/L12 releases where the configuration file format is "toml" but the same process can be used with older LE9.x releases which use a plain-text file format. Look at existing keymaps in /usr/lib/udev/rc_keymaps/ to crib the simple format being used.

No idea on the 4K60 output issue, but:

Quote from Zygmunt

In next step I was testing RPi4 and RPi5 connected directly to LG monitor. I could play my 2160p/60 fps videos H.265 smoothly, but 2160p/60 fps H.264 videos are choppy on both players.

RPi4 hardware decodes H264 and does not support media over 1080p resolution. RPi5 software decodes H264 and will play media over 1080p but H264 is less efficient than e.g. HEVC for the same resolution and H264/60fps/2160p media probbably exceeds the CPU limits of software decoding. Best solution: reencode that media to HEVC and it'll play nicely. Alternative solution: use a recent Intel Core i7 or better device which has the CPU grunt to cope with the non-standard format.

Quote from Zygmunt

Last test - 1080p movies. Both players play 1080p H264 without a problem.
RPi4 has a problem with 1080p VC-1, but RPi5 plays them smoothly.

That's expected. RPi4 and RPi5 software decode VC1, but only RPi5 has the CPU grunt needed for the task.

LewisTowm better to ask the Lakka devs to create an image that uses the LE kernel (or ilmich kernel). They know how to build Lakka. We know how to build LE.

diagus Ethernet issue resolved https://github.com/chewitt/u-boot…b9285bae8061bff

I'll send some patches and an apology to the mailing list and LE master branch soon but https://chewitt.libreelec.tv/testing/LibreE…ek-play2.img.gz contains the fix.

SD cards frequently have different disk "geometry" ensuring the partition data copied from one card is incorrect once written to another card. The solution to that is to prepare the destination card to match the source partition/filesystem arrangement, mount the filesystems, then rsync the contents of the partition(s) instead trying to clone the entire physical (card) disk.

wpa_supplicant is the Xorg of the WiFi world; it's used everywhere, it works, but it's architecturally hideous

iwd is the Wayland that will replace it everywhere, soon, but it's still young(er) and maturing (rapidly).

The latest iwd version bump that went into nightlies a couple of days ago has a pile of fixes for connection issues; the devil is always in the detail but might be worth seeing if anything improves. If it doesn't the investigation process requires you to run iwd in debug mode to capture verbose output traces for bad behaviours/failures and then report them upstream.

NB: LE has long been an advocate for newer and better code that seeks to displace older stuff so we'll be sticking with iwd. It's good to compare with wpa though, if only to help point fingers in the right direction.

Not helpful

I need to bisect the upstream changes between u-boot 2022.10 and 2023.10 (already done 2023.10 to 2024.01). It's a slow process as beyond a certain point you need to add patches to create WP2 support.

smb:// would be a valid URI, smb:/// would not be valid. Edit the file and reboot, see what happens.

I've not seen reports of anything similar sounding.

Omega RC1 has shipped (on the Kodi side, we'll be a couple of days probably) so the code is believed to be complete .. until more issues are found that need fixing. So best to post/share the issues and get them documented and public; else Kodi devs assume all is good and won't fix the (unknown) issue. Post the Q with a "not sure if this is the right place, mods please move if not" and if it's the wrong place it'll be moved.

Connect the drive to a Windows box, run chkdsk.exe to fix the dirty NTFS filesystem state, then reconnect to the RPi4 and turn everything on again. Rinse/repeat when the problem inevitably reoccurs at some point

If you scraped media into the library from smb://nas/share/files, this is the path stored in the library. If the NAS is now accessed using smb://192.168.1.10/share/files the path is different and Kodi treats this like new files.

First, try this to see if it restores name resolution:

echo "192.168.1.10        servername servername.local" >> /storage/.config/hosts.conf
reboot

Or experiment with path substition https://kodi.wiki/view/Path_substitution