Posts by HarryH

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.

"KEY_KBDILLUMDOWN" ???
The linux keys you can find here:

linux/input-event-codes.h at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

I think the way via kodi.log or ir-keytable is more promisioning:
List of keynames - Official Kodi Wiki

xbmc/xbmc/input/keyboard/XBMC_keysym.h at master · xbmc/xbmc

Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…

github.com

xbmc/xbmc/input/keyboard/XBMC_vkeys.h at master · xbmc/xbmc

Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…

github.com

xbmc/xbmc/input/keyboard/XBMC_keytable.cpp at master · xbmc/xbmc

Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…

github.com

tomybyte ,

only to be sure. After you wrote a file to the external NTFS HDD, you disconnect (unmount) properly via taskbar icon and waited until Windows said "it's safe to unplug the device" or something like that, before you physically disconnected the drive?

Safely remove hardware in Windows - Microsoft Support

Quote from ApexDE

so, if i add a NVMe SSD to the Argon case it will be booted by default? (over the microSD being in place?)

I can't answer that with certainty. I don't have a RPi5 myself. But I know that many things have changed in the bootloader and to many users fiddling with outdated parameters. Therefore my recommendation is to start with the only needed settings.

Because some weeks ago the official M.2 HAT+ (incl. specification) was published and advertised to automatically add the NVMe as boot device if detected, I'm expect that booting from NVMe is now also possible via default. Maybe this works with HAT+ only, and therefore not with the Argon ONE V3.
However, to persist the boot order like you want, I would prefer to set it via EEPROM.
EDIT: The advertisement was misleading, the official M.2 HAT+ requires too, to set the boot order in EEPROM like I described above.

If you need additional settings like PCIE_PROBE=1 or dtparam=pciex1 / dtparam=nvme to get it detected, then it indicates your bootloader is very outdated or your chosen NVMe not compatible.

chewitt ,

the AMLGX image works for RPi5 too?

With the official 27W PSU, a current bootloader (>= 2024-02-16) in your RPi5 and 100% compatible NVMe you don't need to change anything, because the autodetection should work and tells the kernel all things regarding the PCIe.

Since the Argon ONE V3 does not support the PD handshake internally, these settings are necessary to provide enough power and add the NVMe as a boot device:

• bootloader config / EEPROM

  Code

  PSU_MAX_CURRENT=5000
  BOOT_ORDER=0xf416

  https://www.raspberrypi.com/documentation/…html#BOOT_ORDER

• config.txt

  Code

  usb_max_current_enable=1

If all things work fine and after some days without errors in the kernel log, you could force the PCIe to Gen 3 if you want speed up. But this is alltime out of the current certification for the RPi5 and should observed as a kind of overclocking. Some kind of NVMe seems to need this to (maybe a firmware bug ?):

• config.txt

  Code

  dtparam=pciex1_gen=3

Nice finding.
But if you look at /flash, there is currently only kernel.img available. You will need a custom build for this test.

You can find the file here: /flash/cmdline.txt

Your Pi has no real-time clock, so the 2024-02-27 is the generated fake date during boot until it get a time synchronization via network. The kernel log messages are from your last startup (2024-05-31).

It's good that you hold some spare parts in the back hand. In the last months I have seen some log snippets with much more noise regarding this message:

May 31 11:08:04.570436 RPi5a kernel: nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
May 31 11:08:04.570750 RPi5a kernel: nvme nvme0: Does your device have a faulty power saving mode enabled?
May 31 11:08:04.570864 RPi5a kernel: nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug
May 31 11:08:04.657093 RPi5a kernel: nvme 0000:01:00.0: enabling device (0000 -> 0002)
May 31 11:08:04.657277 RPi5a kernel: nvme nvme0: Shutdown timeout set to 8 seconds
May 31 11:08:04.660439 RPi5a kernel: nvme nvme0: 4/0/0 default/read/poll queues
May 31 11:08:04.670425 RPi5a kernel: nvme nvme0: Ignoring bogus Namespace Identifiers

Yes, at normal desktop computer I wouldn't expect such messages regulary. But also NVMe firmware isn't free of issues. At the RPi5 I know about cases, that it could fixed, if they followed the recommendation and add this to the kernel line in the cmdline.txt.
pcie_aspm=off
Maybe you doesn't need another cable in your current configuration. But you should give it a shot, and check if it disappears after exchange the cabeling.

Quote from WarpLover

Would there be any value in replacing the Rpi5 with the RockPro64, turn on logging, and run it until it reboots? And would those results shed any light on what is going on with the Pi? (as a reminder, the rock sbc randomly reboots in the same way, which is why I bought the pi).

I think you could make that as a cross check and confirm if it really made a reboot or "only" crash of KODI. The latter one could be ends with some needed changes in KODI it self to fix that.
First you could try to start with a fresh installation of LE (for example on a new SD card) without additional add-ons (back to the roots) and try to reproduce the issue. In some thread I have read last days, it rumours that a weather add-on triggered some issues in the background.

PS: You are right, it's always after midnight.

As far as I know:

• The volume control depends on the libCEC Adapter settings at "Settings->Input->Peripherals->CEC adapter".
  The corresponding settings file is there: /storage/.kodi/userdata/peripheral_data/cec_CEC_Adapter.xml
• The internal volume control is disabled, if you set the audio to passthrough. But passthrough could be disabled from backside if "Sync playback to display" is active. Don't know if such settings influences the CEC volume control too.
• The most use case for CEC is to steering with the TV remote control the downstream devices. Also the volume control of AVR / soundbar works like that. The way to control the TV volume seems not supported in all cases. But you could check to ensure that your TV supports that:
  echo 'volup 0.0.0.0' | cec-client -s -d 1
  echo 'voldown 0.0.0.0' | cec-client -s -d 1