[RPi4/5] CEC TV remote control only working after switching sources in versions > LE 9.2

Try LE 13, all the work goes into that, any older releases is at end of development.

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.

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.

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

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.

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

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.

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...