Posts by HarryH

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

Version 1.2.0 released:

added fan control support for ONE V5 with 2 different mechanism:

• Activate RPi5 system fan detection for ONE V5/NEO 5/Raspberry Pi Active Cooler
  Works via sysfs PWM interface (default, if system fan could be detected on add-on startup):
  Should behave like the ONE V1/2/3 fan control with immediate changes after settings changed in GUI and supports different temperature sources.
• Force support for ONE V5/NEO 5/Raspberry Pi Active Cooler via cooling_fan overlay
  If enabled, uses the generic RPi5 fan control at the kernel level with the parameters in the config.txt file. Disables the integrated fan control of the Argon ONE V1/2/3! Advantage: Works independently of Kodi. Disadvantage: With this method, a restart is required after each change to the fan/temperature settings in the GUI for the changes to take effect.

Unfortunately, the Weblate service is currently not working as intended, so the new GUI menu strings are only available in English and German. If there is progress with Weblate (which could take some time) and/or users provide the updated translation file in their native language, some language updates for the add-on will follow.

Hi heitbaum

because of your comment at https://github.com/LibreELEC/LibreELEC.tv/pull/10658 I'm a little confused. What is the intended usage of PKG_VERSION and PKG_REV?

Currently the build process combine both informations like PKG_VERSION + PKG_REV:

• PKG_VERSION="1.1.13" + PKG_REV="0" results to addon version="1.1.13.0".

If both symbols are set, why do you want that the PKG_REV should be increased as well? I'm trying to understand, because in the past I started every time with "0" as long the add-on with the new PKG_VERSION was never build before and uploaded afterwards to the repo. if just the build process needs some changes (without changes of the source package), the PKG_REV can increased additional to force a new version in the add-on repo.

I have seen that you have increased both symbols at the same time: https://github.com/LibreELEC/LibreELEC.tv/pull/10653/files
, but currently couldn't recognise the reason for. For example the filebrowser would results in a version jump: 2.44.2.4 -> 2.45.0.5

Usually increasing PKG_VERSION would be enough to trigger a new add-on version, because 2.45.0 is already a successor of 2.44.2. https://kodi.wiki/view/Addon.xml#Core_elements

Do I missed some other ruleset?

EDIT:

Okay, I have now seen in the add-on repo that the creation process for most (but not all) add-ons behaves differently from the current one for argononecontrol and hides the source version behind a new add-on version that corresponds to the ADDON_VERSION symbol. So I think your assumption was that this is also the case with argononecontrol. Now I understand your objections/intention, but ends with some new questions:

• Should I from now increase every time the last digit (PKG_REV) within the add-on repo of the corresponding LE version, also if it's technically not necessary?
• May it be okay for the future to still have a speaking add-on version, other than the LE 12.x.x.x/13.x.x.x one? Or it's planned/necessary to make it sometimes equal? Reason: The current behaviour is welcome, because the current scheme generates no conflicts with the manually installed versions for testing from GitHub.

Regards,

Harry

I am currently working on version 1.2.0 of the Argon ONE Control add-on, which optionally supports the ONE V5 fan or any RPi5 with a fan installed on the official fan connector. I need a little feedback before the general release in the LE add-ons repo, if possible. If anyone is interested in testing this with an RPi5, please send me a message or leave a comment.

Version 1.1.13 released:

* new GUI language: Bosnian (Bosnia and Herzegovina)
* Disabling the HDD temperature curve prevents unwanted hard drive wake-ups -> [RPi4] Constant access on external drives

Thinking a little further: Have you also considered that the counterpart to the Wi-Fi connection: the router/repeater, might not be "enthusiastic" about this type of connection interruption by the Broadcom client and block the reconnection?

Usualy you should fill the mode whitelist with the resolutions/refresh rate combinations you want that KODI switches to if the media format matches. The available combinations depend on the EDID data provided. Maybe there are some limitations which combinations are supported by RPi4/5 hardware.

It should be enough to set: "Settings \ Player \ Videos \ Adjust display refresh rate = Start/Stop". This prevents that KODI switches back to the default if OSD is open during playback and ensures the best match of your whitelist is used.

EDIT:
race condition, HiassofT was faster...