Posts by HiassofT

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

Mario77 thanks, I could finally reproduce the issue:

The underlying lggpio library tries to create a pipe in the current working directory - when starting the python script via a systemd service or autostart.sh that will be the root directory which is read-only in LE so everything goes south. Running the script from the console will also fail if you "cd /" before...

I'd say this is a major design flaw in gpiozero / lg-gpio (it shouldn't write anything to the current directory in the first place) but fortunately there's an easy workaround:

Change the working directory to a directory where you have write permissions - eg /tmp

In the service file just add a WorkingDirectory setting, in autostart do a cd /tmp before starting the python script.

[Unit]
Description=to control fan based on temperature
Before=kodi.service
[Service]
Type=simple
WorkingDirectory=/tmp
ExecStart=/usr/bin/python3 /storage/.kodi/addons/service.fan/fan.py
Restart=always
RestartSec=20
[Install]
WantedBy=multi-user.target

so long,

Hias

The fan has a 4-pin connector (5V, GND, PWM, RPM/pulse sense input) - like standard PC fans.

DT params to adjust the fan temp/speed curve have just been added to the RPi kernel, I'll update the kernel in LE soon so it'll be available in nightlies - hopefully in the next few days.

so long,

Hias

You can find some - rather outdated, somewhat incorrect and PC specific - background info in the wiki here: https://wiki.libreelec.tv/configuration/edid

Long story short: remove all the stuff you manually added, connect the RPi to your TV and reboot, then run getedid create via ssh and you are done.

That will dump the edid of your TV to .config/firmware/edid, create the necessary edid.cpio initrd so that the edid is also available in very early boot stage - before the .config/firmware overlay is enabled and everything will be fine - no need to manually fiddle around with duming edids, adjusting config.txt and cmdline.txt etc

so long,

Hias

Did you create and enable the edid.cpio initrd as well?

getedid create will all do this automatically but braviaedid.bin looks like you set this up manually.

so long,

Hias

wyup refresh rate switching is essential if you want (micro-)stutter-free, smooth video playback. Cinema stuff/Blu-Rays are usually at 23.97/24 Hz, TV broadcasts at 50 or 59.94 Hz, PC videos often at 60Hz - if your video output mode doesn't match the video's framerate it'll look juddery.

Regarding DV: UHD Blu-Rays have a mandatory HDR10 base layer, so DV on these disc is an additional layer on top and RPi4/5 will output the HDR10 layer just fine - tested that here with 4k (DV) Blu-Ray rips I did on my own with makemkv.

Streaming services with "pure DV content" (without the HDR10 base layer) is another thing, and RPi4/5 certainly wouldn't have the grunt to process that - direct-to-plane rendering works fine for 4kp60 but GL/EGL rendering doesn't - it's too slow, even without shaders having to do tonemapping (RPi's graphics "chip" isn't anywhere near an Nvidia RTX).

so long,

Hias

Hard to say as you didn't post your addon/script but it could be that you may be experiencing this issue https://github.com/LibreELEC/LibreELEC.tv/issues/8447 (which isn't directly related to rpi-tools/gpiozero)

so long,

Hias