Posts by HarryH

Hi chewitt ,

thanks for the review and the helpful comments. I have created another PR9592 for the master branch and updated the existing PR9591 to be able to use it as a backport for LE12.

I have created a pull request with the needed changes. It's my first one, so please be kind if I made some mistakes and need to correct some things to make it acceptable.

Hi QBJack ,

please can you provide the current content of your config.txt

cat /flash/config.txt

and try if the MCU of the case is detected?

i2cdetect -y 1

The output should look as follows, where 0x1a is the address assigned by the MCU:

LibreELEC:~ # i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

If the MCU is not detected but the I2C working without error messages, please power cycle the case (unplug the power supply for some seconds) and try again afterwards.

A separate service shouldn't be running, The addon is running as a thread of the KODI process. You can/should enable the debug logging to get more insights what happens with the addon and please provide a link to the log:

https://wiki.libreelec.tv/support/log-files

If you have previously experimented with other solutions (argon1.sh /argonone.service ...) on your current LibreELEC installation, you should make sure that there are no fragments left that could conflict with the addon.

Are there a chance that the Python bindings for libgpiod are official included into the virtual rpi-tools addon? libgpiod is already part of the system-tools addon, only the python bindings are currently missing.

libgpiod/bindings/python at v2.2.x · brgl/libgpiod

This is a mirror of the original repository over at kernel.org. This github page is for discussions and issue reporting only. PRs can be discussed here but the…

github.com

gpiod

Python bindings for libgpiod

pypi.org

Why?

Since LibreELEC 12 gpiozero is the main module intented to interact with the GPIO pins. But there are some ugly problems:

• gpiozero takes to long to terminate (killed by KODI after 5 seconds during shutdown, may be related to the lgpio issue explained below) and doesn't frees the used GPIO ressources, so it's need to reboot instead of disable/enable the addon to get it work again
• gpiozero is slower than libgpiod because of additional abstraction layers: https://adafruit-playground.com/u/MakerMelissa…-raspberry-pi-5
• lgpio can be used without gpiozero to workaround the blocked ressource issue of gpiozero, but it seems to start some kind of threading as soon the Python module lgpio is imported. The thread with the imported lgpio module doesn't stop within 5 seconds (the hard limit for the CPythonInvoker of KODI) and prevents KODI to restart/shutdown in usual time. It takes 30 seconds to "systemctl restart kodi" or to shutdown LibreELEC if lgpio is directly or indirectly via gpiozero imported in a script addon. Therefore I think rpi-lgpio (RPi.GPIO replacement) will do have the same restriction.

For a cross-check, I compiled the rpi-tools addon for testing so that it also contains these bindings. If I use gpiod instead of gpiozero / lgpio for Argon40 Device Configuration addon the "systemctl restart kodi" takes only 4 - 6 seconds (not 30 seconds), depending how much background tasks are currently running. This will enable again an ordered shutdown, if the remote control power button is used for the case shutdown instead of the KODI menu. Another story with a firmware restriction (10 seconds limit) of the Argon40 case...

Yes, I can include the bindings in the Argon40 addon, but I would prefer a globally available gpiod Python module so that others also have the advantage of choosing the best working module for their use case.

Theoretical it's possible, but seems depends on your existing equipment and cabeling. Within the CEC adapter settings you can configure what should happen on power on/off/standby events of KODI. The issue could be if you need to signal KODI as "active source at startup" to get the TV remote control working for CEC or to switch to the right input, this triggers some TVs to power on.

Wasn't there some fixes in the nightly builds released after 12.0.1 regarding some issues in conjunction with DENON AVRs?

Post

RE: RPi 4/5 + Denon AVR - 4k60 'No Signal' issues

[…]

I have now been running 12.0.1 for a week and have switched my Denon AVR-X 3600H on and off about 10 times, switched sources as well numerous times.

I am pleased to report the issue appears to be fixed. I am running 60FPS 3840x2160 output in settings and it has reliably always displayed since updating. I have not had to reboot the Pi or switch sources to force output.

tomstephens89

September 8, 2024 at 6:58 PM

JohnWayne111 , which version of LE do you have installed? Already tried with a recent nightly build for a cross check?

Quote from Gregor84

Hey, yes, the last nightly works.
Thank you for the hint.
An no, it is a 8GB Raspberry.

But yes, looks like the MCU code is similar what you wrote:

You are the first to confirm my suspicion from the linked thread that equipment variants other than the 2GiB version with this new chip version are in the wild. Nice to know.

It doesn't look that you have got the 8GiB version, looks more like the hardware revision 2712D0 (released with the 2GiB version). Please try a recent nightly build, which includes the needed Mesa driver patches.

Already discussed here:

Thread

[RPi5 2GB] Scrambled Display on Sony Bravia X90L

Hey, folks.

Please be patient with me as I barely pay attention to any of tech around TVs, variants of HDMI, variants of 4K/8K, etc. We are simple folks who just want to watch a digitized collection of our old movies.

I have a Bravia X90L series (55") and I just picked up a Pi5 CanaKit with all of the bells-and-whistles to double-sided tape a LibreELEC media center to the back of the TV over the fireplace. The version of LibreELEC is recent -- whatever came out of the business end of rpi-imager…

wizardly_jennings

October 10, 2024 at 9:50 PM

Only for information: There are also versions in Python3 of these scripts for Batocera, which can be adapted to LibreELEC if required.

GitHub - HungerHa/batocera_remotepi: RemotePi support for Batocera

RemotePi support for Batocera. Contribute to HungerHa/batocera_remotepi development by creating an account on GitHub.

github.com

Version 1.1.3 released:

• added Dutch translation (thanks to emv-nl)
• prevention of unnecessary I2C messages for updating the fan speed

I didn't want to distract. Nice to know that LE itself shouldn't be affected. It was not obvious to me whether it was mounted exclusively via LE and not via the operating system. And because I could reproduce the issue with 2 desktop linux clients in daily use too, I would only ensure that RomanHT is aware of it.

Most of the usually LE traffic is read-only (with the exception of TVheadend recordings, etc.), but he writes from LE device to NAS so that he could have been affected ...

Sure, the freeze problem itself is another topic.

The board mentioned by popcornmix works for RPi4. You can teach a remote button of your choice to the board or use the shown button to turn it on and off. I know this because I corrected the required scripts for some people on this and another forum and got some positive feedback. But unfortunately, it's discontinued and may not be officially compatible with the RPi5 (integrated max current limit of the RemotePi board).

Regardless of your current freezing problem, I would not recommend transferring (writing) data via SMB as long as the kernel version used is greater than 6.2.16 and less than 6.10.9. There exists a ugly regression and a high risk that you get corrupt data

[REGRESSION] Corruption on cifs / smb write on ARM, kernels 6.3-6.9 - James Young
Intermittent data corruption probably in Linux 6.6.52 SMB client - Zack Weinberg

I do not believe that it was the intention of the developers/maintainers ... of LibreELEC was to break something. And the root cause is an edge case in the concept of how lgpio works and not a problem of LibreELEC.

I know it's hard to accept, but if you look in detail, you'll realise that all modern operating systems try to protect themselves against malicious changes. This will also be the reason why most paths are in a read-only file system. lgpio should be able to handle this, but it doesn't automatically. Therefore the needed hint with the working directory.

A customised addon version like the one you provide for users of older scripts as a starting aid is well-intentioned and also helpful for the initial approach. However, it also needs a maintainer for further updates of the included Python modules to ensure compatibility to new kernel versions, RPi hardware versions and so on. Some approaches such as rpi-lgpio are also only a compromise and do not behave identically to the widely used RPi.RPIO in 100% of the use cases. Especially in terms of performance (regarding this gpiozero seems the worst one, because it's a additional layer). So sometimes it is better to deal with the new variants like lgpio or gpiod (libgpiod) directly. Otherwise it's just a long languish.

But that's just my own opinion...

As long your YAMAHA AVR doesn't pass through the EDID data without cut off the important resolutions/information, Da Flex suggestion is a workaround to use AVR (Audio only) and the TV connection simultaneous.

Do you have already checked if you have the recent firmware version for your AVR? It seems that the AVR currently does something wrong. In most cases, such problems can be resolved by updating the firmware or sometimes by using a different HDMI input on the AVR.

The script itself is working, but you must add a workaround for lgpio. Please try that version:

#!/usr/bin/python

import sys
sys.path.append('/storage/.kodi/addons/virtual.rpi-tools/lib')

from gpiozero import LED, Button
from signal import pause
import os
import time

# workaround for lgpio issue
# https://github.com/gpiozero/gpiozero/issues/1106
os.environ['LG_WD'] = '/tmp'

# Stel de LED en de knop in met BCM pin nummering
led = LED(6)  # Fysieke pin 31 is BCM pin 6
button = Button(13)  # Fysieke pin 33 is BCM pin 13

# Zet de LED uit
led.off()

# Definieer de shutdown functie
def shutdown_system():
    os.system("sync")
    time.sleep(1)
    os.system("shutdown -h now")
    sys.exit()

# Koppel de shutdown functie aan de knop
button.when_pressed = shutdown_system

# Houd het script draaiende
pause()

As your RPi is supplied with power via the HAT, you may encounter another problem. You are bypassing the negotiation via the Power Delivery protocol. So I assume the RPi5 is limited to 3000mA by default. Please see my comment from here:

Post

RE: [RPi5] HiFiBerry Amp4 Pro

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…

HarryH

June 23, 2024 at 12:23 PM

Have you already tried the slave setting required for the RPi5?
Changes in HiFiBerry drivers | HiFiBerry

If that doesn't help, please enable debug logging, reboot and provide a full debug log: https://wiki.libreelec.tv/support/log-files