Posts by HarryH

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.

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