Posts by HarryH

    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.

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

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

    Hi guys, please remain relaxed. There is no reason to curse the case itself, this time. ;)

    ajne
    I will look into this, but I need some time to simulate your configuration in order to find a more practical solution. In the meantime (untested), you can change line 432 in this file:

    nano /storage/.kodi/addons/service.argononecontrol/resources/lib/argon.py

    from val = argonsysinfo_getmaxhddtemp()

    to val = 0

    Restart KODI afterwards or disable/enable the addon to activate the changes.
    systemctl restart kodi

    Your TV set switches to the ‘active source’, which is normally intended. How it reacts on simultaneous "active sources" depends on your TV. As a rule, the active source that is reported last wins. This could lead to the situation that you have to wait until the satellite receiver reports itself as an active source after startup. You could also start this satellite receiver only and patiently wait until this activates the TV.
    With some TVs, you can set a specific external input as the standard for watching television.

    Maybe a mitigation is possible if you disable "Switch source to this device on startup" and/or "Wake devices when deactivating the screensaver" in the "CEC Adapter" settings of LibreELEC: Settings -> System -> Input -> Peripherals -> CEC Adapter

    However, this could also lead to some problems, e.g. that the remote control via CEC not working properly or partially only because another CEC device is being controlled or similar.

    Stuntel ,

    You should make sure that you use the HDMI port that is closest to the USB-C port. Then CEC will work again. 12.0.1 temporarily supported CEC on both ports, but there were too many unresolved issues, so support was limited to the first HDMI port.