Posts by HarryH

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.

enable_uart=1 NOT fixing core_freq to 250MHz · Issue #4123 · raspberrypi/linux

Is this the right place for my bug report? I hope so, apologies if that's not the case. I've also posted on the RPi forum (See…

github.com

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:

• higher power consumption, no clock down during idle
• maybe shortening lifespan of the RPi4, because the clock should be set to 550Mhz to be fast enough for 4K

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 pn

The bad case matches to: „Known Issues“ and „Workaround after improperly shutdown“

GitHub - HungerHa/libreelec_package_argonforty-device: ArgonForty Device Configuration Add-On for LibreELEC

ArgonForty Device Configuration Add-On for LibreELEC - HungerHa/libreelec_package_argonforty-device

github.com

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

Quote from MaxMustermann

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.

Which remote control do you use?

Normally CEC is intended to use the remote control o the TV (or an universal one) to control the other downstream devices via TV. Because the TV (HDMI sink) is the boss. It seems to me, that your TV has an issue to switch back to TV speaker mode or you must somethere enable it. Maybe a firmware update of the TV/AVR is needed to correct this, if it's not only a setting issue.
The volume information up/down are send from TV to the AVR, not by the Pulse-Eight device. The Pulse-Eight device is in that case only a consumer.

This may differ if you try to control KODI directly with a separate remote control. I never tried CEC in this direction, if that supported, besides some debug sessions with cec-client.

libCEC is the underlying library which KODI currently use to provide CEC support, provided by Pulse-Eight. KODI is only a client/consumer of libCEC. The library does the CEC communication and so on.
All things that works with cec-client should also work/be possible with KODI. If threre is a difference in behavior between KODI and cec-client, then it will be an issue of one them.

If both (cec-client and KODI) behaves same, but wrong - then it indicates for an error of libCEC or the involved HDMI configuration/driver/firmware/hardware like RPi, AVR / TV ...

cec-client is nice to debug CEC messages or to send commands via script. Maybe you can see on that way if there any messages are send as soon you power off your TV. Normally your AVR should react on the message from the TV, but:

• the TV must send this message
• it must be allowed in your AVR to power off via CEC

This should be possible independent to the RPi5 behavior. If not, you have already an issue with your HDMI configuration of the TV/AVR or one of the other devices disturb the bus. In the worst case you should start with a single physical connection TV <-> AVR, then TV<->AVR<->RPi5 only and so on to check which one is the disturbing device. Hopefully not the RPi5.

Also the most propagated hint of chewitt : Power off and un-plug all involved devices. Go away and trink a coffee, tea or something like that for least ten minutes, can be a magic healing. Because that ensures that really all HDMI partners were off/reset and the handshaking is initialized new.

By the way, cec-client could also be used as a workaround during boot to power on the TV too via autostart.sh or something like that, because the CEC interface must not be occupied by another client such as KODI at this time.

Quote from olze

I checked the settings and noticed, that after a restart, most of them are set back to default, e.g. i configured its connected to TV / AVR, but when i reboot, it states only TV, which is wrong.

That's the issue that I already tried to communicate twice to you and the reason for that recommendation:

Quote from HarryH

The issue is, that this manual setting will be overwritten automatically after you closed the settings dialog or reboots KODI. This seems intended by libCEC as long the auto detection works.

In my experience it's better to leave this settings at default and don't change that, although sometimes the correct addressing is displayed:

HDMI port number: 0
Connected to HDMI device: TV
Physical address (overrules HDMI port): 0

Quote from olze

I assume thats the reason why its not working.

I will test maybe this evening or tomorrow how LE12 behaves.

Maybe it works with your configuration. IIRC it hasn't worked for my configuration to shutdown KODI via TV off in LE12. I switched to another solution and allow KODI to power off after 120 minutes in idle state.
Until now I doesn't have investigate into the deep regarding this. But I believe the partitially reset of the CEC Adapter settings, because of the auto-detection isn't the same issue. Maybe the EDID data plays a role, but TV on/off commands shouldn't depend on a correct HDMI port information. It's a global command at the HDMI net. It looks more like a timing or order issue to me.

Quote from olze

In the CEC configuration it starts with 1, so i assume 1 == 0 and 2 == 1, right?

No. This setting is to select/address the right HDMI input on your TV, not the output of the RPi ! This should important for those functions:

• Switch source to this device on startup / Beim Starten Kodi als aktive Quelle melden
• Action when switching to another source / Aktion beim Umschalten auf eine andere Quelle
• Send "Inactive source" command on shutdown / Beim Ausschalten Kodi als inaktive Quelle melden

One of the 2 CEC Adapter entries in the peripherals (Peripheriegeräte) list equals to HDMI 0 and the other to HDMI 1. Currently it makes not really a difference which entry you use to configure, because it results in the same configuration set.

Try to imagine the HDMI chain like a pyramid:

        TV 
        AVR
RPi | Bluray | Game console

The root device is mostly a TV (HDMI sink) with the address 0.0.0.0
Every connected device get a physical address with that pattern : 1.1.0.0
The first digit is the HDMI port number of the TV
The second digit is the HDMI port number of the AVR

Example 1:
RPi is connected directly to HDMI 1 of your TV: 1.0.0.0

Example 2:
RPi is connected via AVR to the TV. AVR is connected to HDMI port 2 of TV.
The RPi is connected to HDMI port 3 of the AVR: 2.3.0.0
Bluray at HDMI 4: 2.4.0.0
Game console at HDMI 1: 2.1.0.0

This addressing is important if you want to signaling the device as the current source, so the TV and AVR switch to the right HDMI inputs and you can get a picture and sound. libCEC seems to detect this address automatically.

However, you could set this address manually via one of these:

• "HDMI port number / HDMI-Portnummer" + "Connected to HDMI device / Verbunden mit HDMI-Gerät"
• Physical address (overrules HDMI port) / Physikalische Adresse (verwirft HDMI-Port)

In case of example 2:

• The correct value for physical address is 2300

  or

• HDMI port number: 3 + Connected to HDMI device: AVR.

  or

• Alternatively HDMI port number: 2 + Connected to HDMI device: TV
  

The issue is, that this manual setting will be overwritten automatically after you closed the settings dialog or reboots KODI. This seems intended by libCEC as long the auto detection works.

In my experience it's better to leave this settings at default and don't change that, although sometimes the correct addressing is displayed:

HDMI port number: 0
Connected to HDMI device: TV
Physical address (overrules HDMI port): 0

You can check the current addressing in this way:

• stop KODI
  systemctl stop kodi
• scan CEC bus
  echo 'scan' | cec-client -s -d 1

Like fezster already researched. The technical specification of the QE55Q70RAT are still available at SAMSUNG website: ARC

Just a shot in the dark. Please try it with a current LE13 nightly build.

EDIT: It looks like ARC only, not that eARC is working between your TV and soundbar. This limit the supported sound formats. Could caused by cabeling, firmware issue of TV or soundbar... I found some discussions regarding that, that it happens especially with Samsung 2019 / 2020 TV model line.

Does your Sonos support eARC or ARC only?

Either you change the settings in both CEC Adapter entries sequential to identical settings. Sound weird, but should work. Or you change only in one of them and make a KODI restart afterwards.

Only some other observations remains, which I had already made before with LE 12. Manual set of HDMI port or changing "Connected to" from TV to AVR doesn't resist and is reset after a restart. There seems some interference with a kind of HDMI hierachy auto-detection and should only be used if auto-detection fails completely. All other settings like repeat rate and so on works fine.

With the nightly builds there is some progress in the CEC adapter settings. Somethere I have read, that libCEC is able to support CEC on both HDMI ports. This is the reason for /dev/cec0 and /dev/cec0. It was introduced with LE13 nightly - I don't know if planned or not. LE12 should be expose only 1 CEC adapter.

During my tests last week with a LE13 nightly build, I had the same experience like you, that it feels not consistent. Afterwards I stumbled over the configuration file '/storage/.kodi/userdata/peripheral_data/cec_CEC_Adapter.xml'. This includes only a single set of settings. I fear it's not fully implemented yet to support splitted settings for HDMI 0 and HDMI 1. The last one wins, sometimes only after a reboot.

EDIT: found, seems planned

cec: Allow cec driver to handle multiple instances by popcornmix · Pull Request #8812 · LibreELEC/LibreELEC.tv

Currently on a Pi4/5, LibreELEC is largely usable when connected to second hdmi port, except CEC doesn't work as it's hard-coded to /dev/cec0. This generates…

github.com

LybsterKodi,

you skimp a little bit on detailed information, so it's like looking into a crystal ball.

I don't assume this is the solution for the Options button over CEC, but do you know the Panasonic specific behavior (should also be explained in the manual)?: https://github.com/Pulse-Eight/libcec

Hint: If available, try some other buttons (the period key for SONY Android TVs, RETURN at old Samsung TVs) on your remote if this triggers the ContextMenu by default.

The recommendation of Da Flex is sometimes the only workable way if the chosen TV doesn't pass through the menu keys via CEC.