Posts by HarryH

Quote

Please clarify what test you mean with "first test" so I will gladly test it too. If you refer to this test I have done it and my last logs belong to this test as I said.

There may be a misunderstanding, but I didn't need a protocol for this initial test:

Quote

• Ensure Devices to power on during startup is set to TV -> Some variation of 'One Touch Play' or the first of the 2 commands only.
• Ensure Switch source to this device on startup is Enabled -> triggers the <Active Source> message
• If not already done, switch the TV to HDMI1 (where the RPi is physical connected to)
• Power off TV via remote control
• Restart the RPi4/5 (via SSH) or perform a cold start.

Does the TV power on automatically and the remote control work then within KODI, without having to switch back and forth between the internal TV tuner and the other source first?

I would like to see (and hopefully you report ) how your TV reacts to this - something that cannot be determined from the Kodi log - specifically whether the TV turns on and enables the forwarding of remote control commands to KODI. Since the RPi was previously connected to the slave port, the test could not have been performed correctly.

The second test with cec-ctl -w -M is to identify some by TV initiated CEC messages, which we can use to differentiate if the TV is on and sending of <Active Source> message by KODI is 'desired' or 'not desired'.

• 'Desired' equals: TV was powered on and starts at HDMI 1 where the KODI is connected to. Must lead to <Active Source> and afterwards <Menu Status> messages to show a picture by KODI and activate the TV remote control routing.
• 'Not desired' equals: TV was powered on and starts at internal TV tuner, App or another HDMI port than HDMI port 1. KODI shouldn't send <Active Source> in that case.

Yes, that requires a bit of CEC "magic" via polling - in case the TV isn't communicative right out of the box - but in principle, it is doable.
Only use 'polling' would lead to additional CPU load and require a background thread/service or an add-on to observe the CEC bus, therefore the preferred way would a trigger message which can processed by libCEC.

Quote

I'm fine with the CEC specification because once everything works ...

That sound more that you are not fine with the CEC specification, because your setup and desire currently in conflict with that in some important details.

To be the <Active Source> is a requirement to get the TV remote control routed to the connected HDMI device. One of the HDMI devices is ever the active source. The last one which signaled <Active Source> wins. For example if the TV is believing it was the last one, then the TV doesn't route the remote control keys to an attached HDMI device. This is the situation you have.

Therefore you will require a kind of "Switch source to this device on startup". Something like "React to <Request Active Source> messages" would be better. After such message the active source needs to identify itself using <Active Source>. However, since your setup consists only of the TV and KODI, it has to be the one to identify itself. Right now, my goal is to figure out how your Panasonic handles this. That is the only way we have a chance of bringing about an improvement in the long run. The current software version certainly won't achieve that out-of-the-box.

The test I suggested has nothing to do with your final setup. Its purpose is simply to determine whether and how your TV reacts. Based on the results of some tests, we could then try to:

• Find a "hacky" workaround via cec-ctl
• Report the detailed issue to libCEC and/or KODI
• Try to submit a patch

As you skipped the first test, information to near down the behaviour of your TV is missing.

You hadn't mentioned the detail about the master-slave power outlet before, but it is important. For the test, the RPi4/5 should not be connected to the slave socket.

There is a second test I would like you to perform; this requires the RPi5 to remain on while you turn the TV off and then back on again using the remote control.

Be aware: The KODI debug log won't provide enough information in this second test case. Instead, running cec-ctl -w -M and paying close attention to the messages displayed via SSH when the TV is turned on will reveal the CEC messages the TV sends out on its own.

You should get some output like this: RE: LE13 - TV CEC Remote loses control of Kodi, when TV switched OFF and back ON.

Quote

If I set Devices to power on during startup to None then Switch source to this device on startup gets automatically disabled after reboot.

Unfortunately this is one of the caveats of the current KODI/libCEC behaviour. The CEC specification supports separate usage of :

• 'One Touch Play'
  The combination of power on TV/projector: <Image View On> and switch to the active HDMI input: <Active Source>
• Switch to the HDMI input where the sending HDMI source is connected to <Active Source>.

The corresponding CEC messages are shown in angle brackets.

Could you please check:

• Ensure Devices to power on during startup is set to TV -> Some variation of 'One Touch Play' or the first of the 2 commands only.
• Ensure Switch source to this device on startup is Enabled -> triggers the <Active Source> message
• If not already done, switch the TV to HDMI1 (where the RPi is physical connected to)
• Power off TV via remote control
• Restart the RPi4/5 (via SSH) or perform a cold start.

Does the TV power on automatically and the remote control work then within KODI, without having to switch back and forth between the internal TV tuner and the other source first?

Background: My assumption is, that your TV doesn't send a working trigger for the current libCEC implementation to be notified that the TV is back again. Usually the CEC message like <Set Stream Path> is intended for by specification. I know that some TV doesn't send this CEC message after the TV was powered on by remote control. However, they usually send this message after a source change, e.g. internal tuner <-> HDMI port, since according to the specification it is mandatory to inform HDMI switches about a new route. That would explain the behaviour you have already described.

As a result of the missing or ignored trigger message, KODI does not send a <Menu Status> command to request the routing of the TV remote control buttons. Depending on their firmware level, newer TVs with CEC 2.0 upwards route every time (also without <Menu Status>) the remote control keys to the <Active Source> - as it's recommended for the 'One control' steers all idea.
Important: If the <Menu Status> message is required for the TV, the sending HDMI device must be registered as the <Active Source> in beforehand! Maybe you recognise better now the dilemma with the current CEC Adapter settings behaviour, we have to fight against.

While there are other ways to detect via CEC that the TV has become available again, I am afraid such specific solutions have not yet been implemented in libCEC. I haven't examined the libCEC and KODI code in detail yet, as I am not familiar enough with C++ to quickly get an overview.

To make it short: Selecting from your list, the 12.2.x would be the worst combination in my experience to get a reliable CEC setup.

Since you already stumbled over the thread with the required information about the CEC mechanism, you have seen my postings there as well - or was it written to technical by me and you skipped that?

CEC behavior relies heavily on a stable HDMI connection with valid EDID information. But this kind of error is known and harmless for your issue:

2026-09-18 15:19:36.065 T:875     error <general>: [display-info] Error parsing EDID:
2026-09-18 15:19:36.065 T:875     error <general>: [display-info] ----------------------------------------------
2026-09-18 15:19:36.065 T:875     error <general>: [display-info] Block 1, CTA-861 Extension Block:
2026-09-18 15:19:36.065 T:875     error <general>: [display-info]   Colorimetry Data Block: Reserved bits MD0-MD3 must be 0.
2026-09-18 15:19:36.065 T:875     error <general>: [display-info] 
2026-09-18 15:19:36.065 T:875     error <general>: [display-info] ----------------------------------------------
2026-09-18 15:19:36.065 T:875      info <general>: [display-info] make: 'Panasonic Industry Company' model: 'Panasonic-TV'

As far as I recall, the HDMI handling changed fundamentally after the underlying display architecture was switched - starting with LE 10 - to the standard Linux kernel mechanisms (including drivers, libCEC, Kodi, etc.). That will be the trigger of your observation with a RPi4.

Am I right, your physical HDMI connection looks like this? Please correct me if I'm wrong:

• HDMI 0/HDMI-A-1 (port nearest to USB) Pi5 -> Panasonic TV HDMI port 1
• Other HDMI components like a HDMI splitter, HDMI switch, AVR, Soundbar or a device for fancy LED ambilight are not involved, right?

Please post the current settings of your CEC Adapter within KODI GUI of the LE 13.

It seems that KODI is still hard coded to the AVR (audio system). So it requires the hacky way.

Create the python script "/storage/.kodi/userdata/keymaps/cec-volume.py".

#!/bin/env python3
import sys
import os
if __name__ == "__main__":
    key = sys.argv[1]
if key == "up":
    cmd = "cec-ctl -s --to 0 --user-control-pressed ui-cmd=0x41"
elif key == "down":
    cmd = "cec-ctl -s --to 0 --user-control-pressed ui-cmd=0x42"
elif key == "mute":
    cmd = "cec-ctl -s --to 0 --user-control-pressed ui-cmd=0x43"
os.system(cmd)

And additional the "/storage/.kodi/userdata/keymaps/keyboard.xml" to override the current action mapping of the volume keys of your keyboard.

<keymap>
  <global>
    <keyboard>
      <volume_down>RunScript(/storage/.kodi/userdata/keymaps/cec-volume.py, "down")</volume_down>
      <volume_up>RunScript(/storage/.kodi/userdata/keymaps/cec-volume.py, "up")</volume_up>
      <volume_mute>RunScript(/storage/.kodi/userdata/keymaps/cec-volume.py, "mute")</volume_mute>
    </keyboard>
  </global>
</keymap>

Works with a recent LE 13 nightly. That should work for you, too. But please keep in mind, that's only a workaround.

The correct implementation would be:

• That KODI dynamically switch between TV or AVR depending on the current state of CEC "System Audio Status".
• Only if CEC is disabled (or remote control routing explicit deactivated), the internal volume control of KODI should be used.

Technically speaking, controlling the TV's volume via CEC is possible. Sometimes, this also depends on the specific TV being used. But I'm not aware of the current KODI state regarding this: CEC volume control of TV and AVR

However, the most important requirement is: Does your PC have a functioning CEC adapter?

Depends on how your HDMI switch works. The modern approach should utilize CEC routing information. This will work only if the HDMI source (KODI) is configured and behaves right. As there were many bugs within libCEC and KODI as well, I recommend to skip LE 12.2.x if you are depend on working CEC. Please try with an LE 13 nightly image of 2026-05-14 and upwards and prevent usage of 'getedid create' as the static EDID information disturbs the CEC negotiation in my experience.

With my RPi4 setup this parameter added to kernel boot line cmdline.txt was required to get a working HDMI0 output with 12.2.x.

video=HDMI-A-1:1920x1080M@60D

But with LE13 nightly 2026-04-20 upwards, this line prevented CEC from working right and should removed!

PS: I haven't tested this myself, but with a current LE13 nightly build, CEC should also work on HDMI1. But HDMI0 remains the recommended port as the optimized GPU capabilities (RPi4 resources/firmware limitation).

UberNewf ,

as I already mentioned. In your configuration, connmand adjust a second time, that is wrong. Should only happen once from: 2026-07-23 (libc release -> start date) to today.

Jul 23 13:07:11.767278 LibreELEC connmand[516]: Setting domainname to NewfieNet.home
Jul 23 13:07:11.801306 LibreELEC connmand[516]: eth0 {add} address 10.0.0.82/24 label eth0 family 2
Jul 23 13:07:11.802613 LibreELEC connmand[516]: Skipping server 10.0.0.1 KoD code RATE
Jul 23 13:07:11.876947 LibreELEC connmand[516]: ntp: adjust (jump): +1285421.214827 sec

You will drift away an additional day into the future with every additional day calculated from libc start to today, because it's adjusted a second time with the same delta:

Aug 07 10:10:53.092100 LibreELEC connmand[516]: ntp: adjust (jump): +1285421.214957 sec

My router provides also a local NTP and it works fine with LE, so it appears an issue triggered by your specific configuration. The resulting behaviour of connmand appears strange to me, but the following line could be the cause:

Jul 23 13:07:11.802613 LibreELEC connmand[516]: Skipping server 10.0.0.1 KoD code RATE

Your pfSense is rejecting the NTP client requests because they are occurring too frequently. You should disable or adjust the "Kiss-of-Death" settings in the pfSense configuration and try again.

connmand is adjusting twice:

Jul 23 13:07:11.494065 KODI-BED connmand[565]: Interface eth0 [ ethernet ] state is configuration
Jul 23 13:07:11.506966 KODI-BED connmand[565]: ipconfig state 3 ipconfig method 1
Jul 23 13:07:11.521631 KODI-BED connmand[565]: Interface eth0 [ ethernet ] state is ready
Jul 23 13:07:11.521689 KODI-BED connmand[565]: Interface eth0 [ ethernet ] is the default
Jul 23 13:07:11.521706 KODI-BED connmand[565]: Setting domainname to NewfieNet.home
Jul 23 13:07:11.556887 KODI-BED connmand[565]: eth0 {add} address 10.0.0.82/24 label eth0 family 2
Jul 23 13:07:11.557778 KODI-BED connmand[565]: Skipping server 10.0.0.1 KoD code RATE
Jul 23 13:07:11.593121 KODI-BED connmand[565]: ntp: adjust (jump): +1282755.551565 sec
Aug 07 09:26:27.146046 KODI-BED connmand[565]: ntp: adjust (jump): +1282755.552203 sec
Aug 22 05:45:42.790749 KODI-BED systemd[1]: Finished wait-time-sync.service.

1787237407 is 2026-08-20 16:50:07 CEST, so KODI is correct.

Perhaps I shouldn't pass up this opportunity. Can you install a Kodi add-on that lists the lucky numbers from the past 14 days and sends them to me?

I'm currently on travel and can not have a look into the settings menu itself, so recovered only from my mind: "Make KODI the active source when starting" should be enabled. But your log output already looks so.

Also I can see that the CEC line is shortly disrupted during AVR off and on procedure. But this is expected, as I know that from my old Denon as well.

Like assumed, the TV sends no stream path information until you switch between the ports manually. At least it looks so. Without timestamps enabled ('cec-ctl -w -M' should enable that and verbose as well) within the log and additional knowing the timestamps for your step list, I 'm not able to be 100 percent sure which messages matches to your 7 steps.

The behaviour of libCEC shortly after sending the stream path information resembles a routine that typically runs after Kodi starts up from a powered-off state. The command sequence triggered in this process is known as "One Touch Play." It is quite possible that the aforementioned fix for libCEC 7.1.1 is the cause of this new behaviour. From the perspective of CEC specifications, the new behaviour is not incorrect (or "more correct"), but your specific use case is not covered (or has never been covered) by libCEC. The difference is simply that this situation is now noticeable.

Some of this behaviour could be intended. The underlying libCEC isn't 100 percent free of bugs. You should have a look with 'cec-ctl -M' via CLI whats happen on CEC bus during TV power off/ power on scenario. Maybe the TV is "old school" and requires the <MENU STATUS> message was sent, to route the remote keys through the HDMI port. With newer CEC versions this is not mandatory and the TV should everytime route the keys (One Remote idea). So it depends on th TV firmware as well.

Since the TV sends the remote key commands to the active source only, the RPi5 must be identified as active source in beforehand of remote key routing. Do you have checked that this option is enabled wtihin your KODI CEC adapter settings?

When you switch the HDMI ports at TV away from the current port and back again, the TV must send a <SET STREAM PATH> command as a routing information. The latter one will trigger the CEC follower (RPi5) to reinitiate some states, depending on the libCEC implementation.

As the routing information must be right, it's very important that the port settings within the CEC adapter setting are correct and reliable. Only beginning with the nightly images nightly-20260420-bbf964a the libCEC 7.1.1 fix was implemented. Now it seems to be able to set correctly that an AVR is in use and the setting wasn't dropped after a reboot. But to get it working, my observation was as follows:

• Don't use saved EDID information (remove via 'getedid delete'). That sounds logical to me as the CEC physical address negotiation depends on recent EDID information and should be not static.
• Don't set "video=HDMI-A-1:1920x1080M@60D" via kernel boot line (cmdline.txt)

Version 1.2.3 released:

• new GUI language: Russian
• updated GUI language: Chinese (Simplified Han script)
• missing Ukrainian description strings added
• corrected a few typos regarding the locale codes
• zh_Hans is now mapped to zh_CN to ensure support for Simplified Chinese, as KODI currently doesn't support zh_Hans as locale code

According to the LE 12.2.0 release notes first paragraph, the 12.2.x was intented primary to update the underlying software stack (kernel, display components, libraries ...) required for the hardware support of new devices, without changing KODI at the same time. As if your hardware does not require the new kernel and libraries, the compatibility with 12.0.x could deliver the better experience.
In my case (RPi4) I had to add the command line parameter since version 12.2.x to force a working HDMI output (EDID data). Maybe some changes in timing of the new kernel trigger that - worked also before without this parameter: video=HDMI-A-1:1920x1080M@60D

Also LE 13 (don't be scared about the nightly build tag) could again have a better user experience, as I assume a recent KODI version is better adapted to recent kernel and library changes.

Do you have already checked against a LE 13 nightly build whether the issue is there too? It's not unusual that also KODI can trigger the problem. It's not expected to get another KODI 21.x release.

I know that the CEC settings with libCEC could be a mess in conjunction with different KODI versions.

Please note, however, that manually configuring the HDMI port and/or physical address is pointless. If no general changes have been made to libCEC, the system will always rely on the implemented automatic detection of this information.

These Information are extracted from the provided EDID data of your TV / AVR combination. If you have some trouble with unexpected port settings, you should investigate there and maybe use getedid create to use a fixed working copy of EDID data. https://wiki.libreelec.tv/configuration/edid

• Physical Address: 1100 would be correct for : TV (HDMI 1) <- AVR (HDMI 1) <- KODI
• Physical Address: 1000 would be correct for : TV (HDMI 1) <- KODI

Explanation of the 4 digits of the physical address from left to right:

• x.1.0.0: HDMI port number of the HDMI sink (TV or Projector) where the HDMI source (AVR, Set-Top-Box, Bluray player, ...) is physical connected to
• 1.x.0.0: HDMI port number of the first HDMI switch (mostly an AVR or Soundbar) where the HDMI source is physical connected to behind the HDMI sink
• 1.1.x.0: HDMI port number of the second HDMI switch behind the first HDMI first switch - seldom in use
• 1.1.0.x: HDMI port number of the third HDMI switch behind the second HDMI switch - seldom in use

The TV / Projector (HDMI sink) is the main component in the HDMI chain (imagine a pyramid) and always has the physical address 0.0.0.0 (unless you connect a second TV at the same time).

Version 1.2.2 released:

• updated GUI language: Spanish (Spain)

Version 1.2.1 released:

• new GUI language: Ukrainian
• updated GUI languages: German, Italian, Polish, Swedish