Posts by HarryH

First: I'm missing the model number of your Panasonic TV.

There multiple opportunities, why the behaviour could have changed since your first observation:

• LE 13 build -> the included libCEC was multiple updated until a recent release to fix libCEC own issues
• KODI 22.x was adopted partly to the new libCEC feature set
• TV firmware could have changed, or the cached configuration at least
• RPi5 firmware was updated
• The TV firmware became stuck in an unexpected state until the device was completely disconnected from the power supply.
• ...

That you get no response to cec-ctl --request-active-source as soon you switch to HDMI 1 is expected as the to that HDMI port connected libCEC/KODI should answer, but doesn't react on own requests. Maybe it's technical desired to prevent a loop.

But: If you get every time phys-addr: 0.0.0.0 reliable as the response as soon your TV is set to the internal tuner, then this could be used as the detection method for a script - if required yet. In my local test cases here this expected response was not stable with my TV / AVR setup, therefore I had discarded this approach like I already mentioned above. Could be different in your specific setup.

You could try to observe the CEC bus with cec-ctl -w -M as soon you can reach the SSH to look how your TV discover the environment. Could be, that your TV require some startup time until it scans the CEC activly after about 1 minute. It's not uncommon that TV firmware takes some time to start all features completely.

A requirement not met in your setup: by design, CEC devices are not fully powered down and should respond to an incoming CEC command within a maximum of about 1.4 seconds.

Whether the buttons on a TV remote are passed on to a connected CEC device depends primarily on the television's firmware - not on KODI (or any other HDMI-CEC device). It's looks like the TV collects within the about 1st minute of operation the information to decide that by self. Initiated by the connected device (libCEC/KODI) the CEC message combination <Active Source> + <Menu Status> triggers the same status - or confirms an existing one. After the minute is expired it could also be the second detection run of the TV, as RPi5 is fast but requires time to boot until KODI with all add-ons is fully started.
This could potentially explain the current behavior. We would only know for sure if we were 100 percent familiar with how the TV's firmware behaves...

Unfortunately 'latest' contain never a kind of useful information. Could you please have a look for a date and the build hash like 'LibreELEC-Amlogic.aarch64-13.0-nightly-20261103-d3cd739-odroid-n2.img.gz'

• 20261103
• d3cd739

Only in this way can the code state be checked and it be ensured that we are talking about the same starting point.

I'm a little bit surprised if you would have the eventlird service available with a recent LE13. Do you have also verified with ir-keytable -t that the EV_MSC with the scancodes and EV_KEY are logged?

Does it make a difference if you stop eventlircd and start KODI without that service?

Do you have prepared the required rc_maps.cfg file now? I'm not familiar with the Amlogic devices and their culprits. Is it a recent LE13 version that do you have installed? Do you have already seen this: Important change in LE13 remote handling ?

Keyboard events were different handled than remote keys. Do you have some customization in place from the past?

According to this: https://wiki.libreelec.tv/configuration/…iguration-basic the "-a" switch is to load the rc_maps.cfg not to load the toml file. So you should make a copy of /etc/rc_maps.cfg or create a empty one, add a line with a reference to your toml file and load afterwards the /storage/.config/rc_maps.cfg via ir-keytable -a /storage/.config/rc_maps.cfg.

The line in the file `/storage/.config/rc_maps.cfg` might look something like this configuration

meson-ir * ru880_vcr-code131.toml

or

em28xx * ru880_vcr-code131.toml

depending on which IR receiver you wish to associate the configuration with.

Only to be safe: Until now, I assumed that your TV sometimes was before the shutdown explicit set to internal tuner or app, not HDMI port 1. An you wish to prevent that this is oversteered by KODI start. I'm right? Or is there another use case, which I'm not aware of it?

Maybe there is another option to figure out if your TV is currently not switched to HDMI port 1. Modern TVs have mostly an IP control option for home automation. Especially for Panasonic it depends on the chosen model. Is your TV connected to the same local network like your RPi? Could you please provide the full model number of your TV?

Perhaps your TV is more “communicative” than mine. You could also check whether the TV provides reliable feedback confirming that it is the currently <Active Source> - especially in cases where, immediately after being turned on, the device is still set to its internal tuner or an app.

cec-ctl --request-active-source

The response should contain something like:

   ACTIVE_SOURCE (0x82): 
       phys-addr: 0.0.0.0

Regarding your question: "Where would the best place be to put this small script in?":

• As long as the single option "Switch source to this device on startup" is not persistent out of the box, then a simple bash script which is called by a systemd service would be my prefered attempt. There could an additional delay implemented, if required. And should also work with KODI service restart. Not the same, but like that: https://wiki.libreelec.tv/configuration/…iguring-systemd
• A KODI script add-on which works as a wrapper and calls that 2 commands in background
• If the mentioned home automation API call to your TV isn't possible as well and you are now fine with the restriction, then the "Devices to power on during startup" set to "TV" which although adds the <Image View On> message, but wouldn't hurt and you could skip a script.

During my local testings it has turned out that <Request Active Source> is not reliable to get an answer. It should, but it doesn't. As your TV maybe emits his indication about a routing change before the KODI is up, these information are also not available.
Additional you explicit don't want, that KODI is all time the initial <Active Source> after TV power-on. So the intended behaviour of recent CEC specification will not help.

Please try to reproduce the situation that the remote control not work after the RPi is powered on via the slave socket.
In that situation please do the following:

• Do not change manually to another TV input
• Connect to RPi via SSH
• Execute the 2 variants and check whether after variant 1 the remote control already works, after the second only or never.

  1. <MENU STATUS> command only:

     Code

     cec-ctl --playback --custom-command cmd=0x8e,payload=0x00 --to 0

  2. <ACTIVE_SOURCE> for HDMI-Port 1 at your TV in combination with <MENU STATUS>:

     Code

     cec-ctl --playback --custom-command cmd=0x82,payload=0x10:0x00 --to 15
     cec-ctl --playback --custom-command cmd=0x8e,payload=0x00 --to 0

The expected behaviour is:

• BIOS/hardware clock is running in UTC
• System boot and catch the value of your hardware clock and translate it from UTC to your local set timezone. The timezone setting template of the system respects also daylight saving dates and add 1 hour in summer months and don't add that 1 hour in the winter months.

As your system sets during shutdown the hwclock to UTC, it's to assume that it also know at boot time that the values from hwclock are UTC. If you would manipulate in BIOS to local time a miscalculation would occur.

What is your reason for keeping the time given in local time? Do you suspect that reference time differs between boot time and shutdown? Please keep in mind that during LE boot typically NTP servers are asked for current timestamp. There are situations known, where a ISP or router provides a wrong timestamp and trigger offset.

Addendum:

If you plan to use some kind of wake up via BIOS schedule, you would require the tool 'rtcwake' to set the next wake schedule automatically. The appropriate place for this would be a startup or shutdown script , but unfortunately, the binary file will be missing. Furthermore, you first need to check whether your Radxa X4 is supported. On that way you would ensure that the time adjustment of the shift date is respected.

Even if you want to stick with local time, you would need to create the file /etc/adjtime with the following content:

0.0 0 0.0
0
LOCAL

Since LibreELEC is based on a read-only file system, you currently need a custom LE image to achieve this - or at least the rtcwake binary that matches your architecture.

You seems to misinterpreting my post.

UEFI or BIOS has since beginning never supported daylight saving (summer / winter time switch) in general. Maybe that are exists some exotic ones.

The BIOS shows the hardware clock time, and therefore it should contain the UTC time, if you want it use with an time zone settings of an operating system. This is independend of the operating systems name: Linux, Windows, MacOS, FreeBSD, Android ...

To set the hardware clock to a value which already includes the timezone differences make it pointless complicated. That was a decision of Microsoft to force that for their Windows operating systems by default, but forces the issues you want to prevent.

Every modern operating system (since more than 20 years ) is able to add the required difference to the UTC value of hardware clock. Only Windows requires the mentioned additional registry key to drop the idea to set the hardware clock to local timezone value.
The default behaviour of Windows is the only known operating system that causes the daylight saving issues, as it updates on every summer time and winter time change date the hardware clock to local time - or changes the time retrospectively at the upcoming days if was shutdown at point in time.

The in the background working Win32 time service covers the issue to often, but in fact it's wrong. Windows is able since the Windows 2000 age at least to add/subtract the required difference to timezone dynamically.
Linux prefer UTC since it's beginning and has only as dirty workaround, for the Windows affected user, an option to set the hardware to local time as well. Some distributions support that now to make the switch more easy from Windows to Linux, but the approach is counterproductive as it leads to the summer / winter time issue in dual boot scenarios.

The technical/mathematical issue with BIOS (hardware clock) in local time is, that every installed operating system is believing to make the required change to the hardware clock. After the event, the operating system sets a flag in the OS internal configuration that it has made the change for this year. This flag is not set in BIOS/UEFI and therefore not available for other installed/bootable operating systems. So if you start the next available operating system it will try to make the change again. Depending how many systems you use in parallel it will cumulate and the shown time will far away from your local time.
Only a working NTP/Win32 time services prevents you in this situation from drifting to far away.

Like mentioned, set BIOS to UTC and you will be fine. Windows installations require one-time the registry key is set.

Yes, you can ignore the technical facts and set the hardware clock to local time. But please don't be surprised if the automatic daylight saving (summer / winter time change) doesn't work like you expected.

Sounds like you use dual boot on your machine. In that case you would thinking in the wrong direction.

If you would use your local time in BIOS, both or multiple operating systems would change the time in your hardware clock and you will end with at least with 1 hour away from your correct time, after summer / winter time change.

The correct way is to set your BIOS to UTC, then it must only corrected if hardware clock differs from NTP time. Requirement: Linux and Windows should set to use UTC for hardware clock to be fine.
The selected timezone within the operating system will then lead to add/subtract the delta automatically to show you the correct local time during your operating system session, without touching the BIOS time.

To set Windows to use UTC for hardware clock there must the registry key RealTimeIsUniversal explicit set: https://the.hosting/en/help/nastro…a-raboty-po-utc

I'm using that setting for dual boot systems without issues for decades.

Version 1.2.4 released:

• new GUI language: Czech
• updated GUI language: Ukrainian

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.