Posts by HiassofT

Use an external (USB) HDMI grabber, this is still supported by current Hyperion. There don't exist any working software grabbers for RPi yet.

so long,

Hias

Do as the same as systemd-shutdown, ignore the message(s) (they are harmless and perfectly normal).

so long,

Hias

It depends on what you want.

By default the RPi uses the (better) ttyAMA0 for bluetooth and you can enable the (less capable) ttyS0 for use in your script with enable_uart=1 in config.txt.

With the miniuart-bt overlay bluetooth uses ttyS0 and you can use ttyAMA0 in your script.

so long,

Hias

Just use /dev/ttyS0 or /dev/ttyAMA0 in your script.

The (downstream RPi) script and udev rule to create the alias symlinks have been removed a while ago when the RPi kernel finally switched to upstream kernel BT configuration.

brcmfmac_sdio-firmware-rpi: drop rpi-btuart script and service · LibreELEC/LibreELEC.tv@690a4fb

Bluetooth is finally initialized by the kernel Signed-off-by: Matthias Reichl <[email protected]>

github.com

so long,

Hias

Quote from Nekromantik

i mostly use san disk usb 3 drive

This doesn't say much, Sandisk has a ton of different models.

I can't test on RPi5 right now but on my PC eg my Sandisk Ultrafit 32GB USB3 stick does about 140MB read / 50 MB write whereas my Sandisk Extreme Pro 64GB microsd card achieves 170MB read / 90MB write speed (both tests were linear reading/writing 1GB of data).

so long,

Hias

It'll depend a lot on the exact model you use, most of the 32-128GB USB sticks I have are a lot slower than the 32/64GB SD cards I use (Sandisk Extreme Pro), especially when it comes to writes and random access.

As a rule of thumb: if the manufacturer didn's spec write speed it'll be slow. For SD cards also make sure you get one with A1 or A2 application class and, as always, stay away from no-name brands.

You'd need to look for USB SSDs (not USB sticks / thumb drives), they should be fast - but they are quite expensive.

so long,

Hias

The journal message already gave you the correct hint: use Option=nolock in your systemd mount unit.

so long,

Hias

Take your time, we're not in a rush.

I had planned to rework our noobs/pinn build a bit in the next weeks or so (as time permits) and it'd be nice to have that finished when we ship LE12.0.0. As we haven't started with LE12 betas yet I'd guess that won't be before March, so there's plenty of time (and it's also no huge deal if we do it some time later, then you/we can just do a manual os_list update).

so long,

Hias

Thanks for adding/updating the os list!

I think moving to sha checksums of the downloaded tarballs etc is a good idea, then we can drop the manual md5 sum creation and checks in partition_setup.sh.

Do you have some pointers how to use/add the pinn sha512 checksums?

In general I'm very open to all improvements and suggestions how to simplify stuff, just speak up

so long,

Hias

This is a known issue and the fix is just waiting to get merged by someone into LE12 https://github.com/LibreELEC/LibreELEC.tv/pull/8509

so long,

Hias

Please test with the latest LibreELEC 12 nightly builds, I recently noticed and fixed an issue which may have led to filesystem writes (updating last file/directory access timestamps) even if you only read from NTFS partitions

NTFS filesystems are mounted with incorrect options · Issue #8474 · LibreELEC/LibreELEC.tv

Automounting NTFS drives via udevil should mount NTFS filesystems with nosuid,noexec,nodev,noatime,fmask=0133,uid=0,gid=0 according to udevil.conf but on LE12…

github.com

In addition to that you can now configure LE to mount NTFS partitions read-only by default which should further help with accidential filesystem corruption in case of unclean shutdown, powerloss etc. If you want to change files eg via SMB share or shell just remount it read-write, eg via mount -o remount,rw /var/media/YOUR-NTFS-DRIVE and remount it again read-only after changing stuff via mount -o remount,ro ...:

Copy /etc/udevil/udevil.conf to /storage/.config/udevil.conf and change the default_options_ntfs line of /storage/.config/udevil.conf to contain the ro option. i.e. add , ro at the end of it:

LibreELEC:~ # cp /etc/udevil/udevil.conf /storage/.config/udevil.conf
LibreELEC:~ # nano /storage/.config/udevil.conf

...
default_options_ntfs      = nosuid, noexec, nodev, noatime, fmask=0133, uid=$UID, gid=$GID, ro
...

so long,

Hias

procount another question: do you support UUID=... instead of LABEL=... in partition setup now? Currently we still have label entries in partition.json but as LABELs can easily clash that's not ideal.

eg https://releases.libreelec.tv/noobs/LibreELE…partitions.json

Also not sure if our partition_setup.sh is still fine https://releases.libreelec.tv/noobs/LibreELE…tition_setup.sh

so long,

Hias

procount currently we only have the latest version available, via https://releases.libreelec.tv/noobs/..., but that does seem to cause issues with the mirrors so we are discussing if we should provide versioned directories.

9.2.6 was our last release for RPi1, RPi2 (also used for RPi3), RPi4 and RPi5 releases are at 11.0.5 now - which was just released today and the mirrors don't seem to have picked up the new noobs files yet.

eg https://ftp.halifax.rwth-aachen.de/libreelec/noobs/ doesn't have RPi5 yet but it's available directly from our release server - eg https://releases.libreelec.tv/noobs/LibreELEC_RPi5/os.json, RPi2 is at 11.0.4 (the previous release) and RPi4 at 11.0.3 (I broke RPi4 and RPi5 noobs builds in 11.0.4 so that was our previous RPi4 noobs release as well).

The easiest solution would be if you could pull a json with the latest noobs image metadata from our server, like RPi imager does - then we can automatically update it when we do a new release.

Regarding image metadata: do you have some info which settings should be in the os/os_list.json files`? Currently we fill in lots of very deprecated fields like supported_hex_revisions which IIRC got dropped ages ago and may be missing some other now required fields.

so long,

Hias

On RPi5 you have to manually run "rpi-eeprom-update -a" via ssh to update the bootloader eeprom firmware.

so long,

Hias

firmware and kernel have been updated 2 days ago and are already in LE11 nightlies

[le11] linux (RPi): update to 6.1.71 by HiassofT · Pull Request #8498 · LibreELEC/LibreELEC.tv

Runtime tested on RPi5

github.com

so long,

Hias

Quote from JohnWayne111

Kodi Nexus 20.3 was released yesterday.

Will there be LE 11.0.5 based on 20.3 or full focus on LE 12?

Yes. We already updated kodi in the LE11 branch https://github.com/LibreELEC/LibreELEC.tv/pull/8504 and if testing goes fine 11.0.5 should be released soon.

so long,

Hias

Quote from yamcenutzer

All these cases that are not FLUSH with hdmi connector will cause problems.

This is indeed a problem with a lot of the cases as that won't allow you to full insert the HDMI plug into the socket, causing all sorts of (intermittent or also permanent) contact problems.

Fortunately though there's an easy workaround: take out your X-Acto knife and trim off 0.5-1mm of the plastic on the front of the HDMI plug. BTDT a couple of times and it fixed my issues.

Issues with bad solder joints of HDMI adapter PCB boards, like inside the Argon cases, are a lot more troublesome to solve though.

so long,

Hias

Great, that lg-gpio issue was already reported almost 2 years ago https://github.com/joan2937/lg/issues/12 but hasn't been addressed yet.

I've opened a gpiozero issue https://github.com/gpiozero/gpiozero/issues/1106 so gpiozero will (hopefully) add the recommended workaround

so long,

Hias