Please try this: Move the import line for os module upwards before you import from gpiozero and insert that line.
import os
os.environ['LG_WD'] = '/tmp'
from gpiozero import PWMOutputDeviceLibreELEC 12 has been hardened. The lgpio module (used by gpiozero) needs a working directory path which isn't write protected: https://github.com/gpiozero/gpiozero/issues/1106
There are 2 things to note in your screenshots:
It's also important to know if you use a case like the Argon ONE V3, because this needs special handling.
But in general, please follow chewitt recommendation and try a new SD card first.
According to this (2.6 Simultaneous Access):
Differences — rpi-lgpio 0.6 Documentation
https://rpi-lgpio.readthedocs.io/_/downloads/en/latest/pdf/
the error messages indicate that the GPIO is already in use. Seems not a fault of the rpi-tools add-on.
Normal behavior of ntpd is to ignore time servers which are more than 1000 seconds away from the current time, maybe this has some influence in your situation.
If you have a RPi5 in use, please be aware that the gpiochip has been reordered back to gpiochip 0 with kernel version 6.6.45 and following.
Maybe this is the issue for not working with 12.0.1.
Your configuration looks to me like common practice and in my opinion it normally should work.
I grabbed this from the known issues part of the GC110 firmware changelog:
If you doesn't have the DHCP L2 Relay / DHCP snooping enabled and accidentally misconfigured, then there seems to be some other "features" available that can be trigger such issues too... 
You are right, my question was not without a troubleshooting background.
In the past, I had a long term NFS troubleshooting with a network newbie as a communication partner. He was using the SG200-08P managed switch, but he didn't mention it. The network had been producing strange problems. NFS connections were not possible between the satellite receiver and the NAS. We spent ages trying out the settings on both the receiver and the NAS. In the end, I was able to convince him to install the latest (also end-of-life for several years) firmware, and voila - the error was gone.
I also know of some old changelogs for enterprise switches that had problems with DHCP relay. So maybe you should look for a changelog for the switch you are using and try to get a newer firmware.
Of course it could also be a problem on the kernel side, but I suspect the number of home users with managed switches is not very large, to get a valid feedback from others.
EDIT:
Depending on the switch vendor you use, "trunk" implies that all traffic at this port is tagged. That means, you must ensure that the client (RPi) know about it and configure the corresponding VLAN ID there too.
One question: Do you have a managed switch (for example Cisco SG200-08P ) in use for your wired network?
Version 1.1.2 released:
For the parameter „enable_uart=1“ is documented that this locks the clock rate as fixed, but as far as I know this is not true.
So since beginning I expected that the I2C speed could make trouble too, because of dynamic clocking. Perhaps this is unfounded for the I2C and only the RPi clock-stretching bug is an issue. Until now I couldn‘t verify that case.
If you can catch a bad case again, please provide the full log, not only snippets. If my suspicion is right, then we will doesn‘t find a difference in the logs, because the issue exists only during transfer of the message at the I2C bus.
To rule out this possible trouble maker we can try to set the clock rate manually. This will have some restrictions like:
By the way: I have also been trying out a different configuration without "enable_uart=1" for several months in order to use a different UART and not restrict dynamic clocking (if it after an kernel/firmware update accidentally works like designed ). This works too, if you can live without the integrated bluetooth adapter.
I doesn‘t have a oscilloscope to see what happens at the I2C bus so I‘m not 💯 sure that could be the solution for the bad case scenario. For the I2C clock stretching bug, maybe slow down the I2C speed helps to mitigate the issue.
I can’t imagine that the firmware has been corrected by Argon40. Also the shutdown should work, after you has confirmed via power menu. If there is no power cut after you triggered the shutdown via remote control, could also be an indication that the MCU is stuck.
I know such behavior if there was send some (un)specific I2C messages for example with i2cdump command to the MCU before. If the MCU is stuck, mostly the fan runs permanently and long press (<= 5 seconds) of the power button doesn‘t work, only unplug of the PSU. <- this matches more to your description.
Do you have some kind of overclocking active? Also other I2C devices/drivers maybe trigger this.
It looks to me, that you are using LibreELEC 11. For RPi5 support, LE12 and the corresponding rpi-tools are needed. With a recent version of gpiozero the SoC detection should work automatically, but you can force that:
# workaround for lgpio issue
# https://github.com/gpiozero/gpiozero/issues/1106
os.environ['LG_WD'] = '/tmp'
from gpiozero.pins.lgpio import LGPIOFactory
from gpiozero import Device, LED
Device.pin_factory = LGPIOFactory(chip=4)Alternatively, this should do the same, like your python script.
#!/bin/bash
/usr/bin/pinctrl -p GPIO17 op dh pnThe bad case matches to: „Known Issues“ and „Workaround after improperly shutdown“
Because the remote control sends „KEY_POWER“ command, sometimes this key is passthrough fast enough, to open the power menu of KODI, before the background service signals the KODI shutdown. But the shutdown should already initiated. KODI 21 takes time…
If without your confirmation, the system doesn‘t shutdown hard (power cut) after 10+ seconds, then it‘s a „new“ behavior of the MCU firmware to me.
Do you have the SD card removed? I‘m asking to exclude that the system sometimes was accidentally booted from SD card with the settings/add-ons from there.
If you enable debug logging you should find Argon40 messages in the kodi.log (kodi.old.log after next boot). If you find an exception message instead of the Argon40 debug messages there, then possibly an bug exists.
The cache is only used when playing large files such as videos. It works/helps not when navigating menus are slowly because of big directory listings.
There exists a refactored documentation in the KODI wiki page:
https://kodi.wiki/view/Settings/Services/Caching
If you get in memory trouble during library listing it's mostly an issue of the skin and/or one of the included components/plugins (some weather add-ons for example). Thats the reason for the recommendation of Da Flex to double check with the default skin.
Because of this: RE: LibreELEC 12.0 RPi5 and NTFS HDD problem
please try a current LE13 nightly.
LieberBieber
because the RPi5 is powered from the backside via GPIO, maybe with the Amp4 Pro you are now in the same situation like the Argon ONE V3 users and needs to tell the RPi5 that the used power supply is strong enough. Especially if you have attached additional USB devices.
Try to get it stable with these configuration changes:
Add these lines to bootloader config/EEPROM:
PSU_MAX_CURRENT=5000
and to your config.txt:
usb_max_current_enable=1
Regarding documentation here is a (maybe outdated) one:
LibreELEC installation and configuration | HiFiBerry
Test the new Amp4 Pro | HiFiBerry
Because of the information in the linked blog, I assume you should use this configuration line for the Amp4 Pro
dtoverlay=hifiberry-amp4pro
I wished the add-on used what is defined in <setting id="connected_device" value="36037"/>
As far as I know this setting in combination with cec_hdmi_port is to override the physical address. (But currently this also not persists, and is reset after a restart, because of libCECs auto-detection). It's not suitable for the volume device assigning.
Would have to be an additional switch or some kind of dependency on the standby states of the TV and/or AVR.
Yes, I think we need a pull request. But you have made the first step in the right direction and pointing to the maybe problematic part. The most sources I found say "It will not work with a TV". Maybe they you use all KODI.
Can you please check if that work for you with the TV volume?
echo volup | cec-client -s -b 0 -d 1
echo voldown | cec-client -s -b 0 -d 1
If yes, the sources I found until now, were wrong.
