Posts by HarryH

Version 1.1.8 released:

• Contains a workaround against the long standing installation bug with LE 10 / 11 that after a installation from scratch a error message was thrown and second reboot was required to activate the I2C bus. Happened only if system-tools wasn't already installed before, like if you installed LE from scratch.
  
  It is therefore more of a kind of clean-up/maintenance of the code to make it reliable for users of the old LE versions 10 and 11. If I look at the download counter at #25 there seems some to stay with LE 10 / 11.

Have you thought about working around the problem with the missing context menu (long press on OK) if you use a separate button on your TV remote control? I'm not talking about customisation via the Keymap Editor add-on.

It depends on the manufacturer and model of your TV. Some manufacturers (e.g. SONY) also support passing through the menu buttons via CEC. Sometimes this function has to be specially configured in the depths of the TV settings, but usually there is also a separate button for the context menu by default.

Maybe this could be an option for you...

chewitt ,

the logic for manual installs from zip is not annoying and works fine, looks as intended. I have actively tested this with LE13 nightly.

Also if the add-on has been installed from zip, an available update from LibreELEC add-ons repo will be announced. At this point you can decide to accept or ignore the update. It will not automatically updated via "Install auto updates only" or a background schedule, because the current installed version is not from a repo, thats the only different I found.
If you accept the announced add-on update from repo via "Install all updates", then you will on track with the repo afterwards and will get all future updates from the repo.

In addition, it is possible to switch to the zip version with the same add-on ID from GitHub, if required. This can be helpful for those affected, for example, if a new version with an urgent change is available but the build/publishing process for the repo has not yet been completed. As soon as the add-on version becomes available in the repo, you can switch back to the repo version and it will be updated automatically from then on.

Of course, it's easiest to just use the repo version. That was the main reason for including it in the repo.

ApexDE ,

triggered by your question I have added a Q&A section to the README at GitHub.
I hope this makes the migration easier and helps others too. Please take a look at it.

It appears what you mix up/create a theoretical issue, which do not exist if you would follow the advice of chewitt and also doesn't exist in practice (especially if the advices in the README at GitHub are not skipped, or those from above).

Because 1.1.7 and 1.1.7.0 use the same add-on id "service.argononecontrol", you will never have installed both version simultaneous. The last installed package version wins and overwrites the other. On that way you could switch between both, if would a different in code. Use case: a newer version is available at GitHub and you can't wait until it's released via the LibreELEC repo.

By the way: If something in the README is unclear documentated, please direct to the paragraph and ask straight forward. Maybe my wording is wrong (I'm not a native English speaker) and can misinterpreted or an information is missing. Sometimes it seems as if only headings are read or entire paragraphs in which the answer has already been given are skipped. The latter is frustrating because I can't fix the behaviour of the readers and it makes additional effort.

For LE13 nightlies the add-on is availabe now via the "LibreELEC Add-ons" repo. I have installed the add-on from there with a recent nightly from scratch and it's working right. It's also offered as an possible update if you manually installed v1.1.7 from GitHub before, but then will not automatically overwritten. Locations to change to the repo version:

* Add-ons / Add-on browser/ Available updates -> Argon ONE Control
* Add-ons / Program add-ons / Argon ONE Control -> context menu -> Information -> Versions -> Version 1.1.7.0

ApexDE ,

the behavior was not changed (also not planned) with regard to the edge use case with the file argon40_rc.lock. Also the naming is left the same because it remains an Argon40 device, and I like short file names for locks.

Regarding your feature request, I have already explained the related caveats/restrictions in the past of this thread. Can you please open an issue on GitHub so that it is tracked and not forgotten.

It should be updated automatically when a newer version is available in the repo. But without a version of the add-on available via the repo, I could not verify this yet. Normally this works if the last digit is increased by at least 1. But currently the count of digits in the version string differs 1.1.7 (GitHub) vs. 1.1.7.0 (Repo). So the final answer is outstanding, or the behaviour must simulated with another installed plugin.

Version 1.1.7 released:

• add-on id has changed, as a prerequisite for the upcoming integration into the LibreELEC add-ons repository
• because the id change was required, also the name has changed to distinguish better from the outdated official add-on variations 0.0.1 from Argon40

• icon changed
  
  New name: Argon ONE Control
  
  For more details please read the documentation at GitHub entirely.
  
  The add-on has been under review for approx. 2 months because, among other things, the ID had to be changed. One consequence of this is that an existing older version must be removed before a newer version than 1.1.5 is installed. However, the current customised settings are lost in the process. This is only necessary once.

  The release process is not yet complete. Only then will it become available in the LE add-ons repo. I hope that no further adjustments are necessary so that it can be included.

Hi Alex,

all available resolutions in KODI, including those you want to select for the whitelist, are based on the EDID information. If the EDID information is incomplete/incorrect, then the GUI settings may change with each restart. Details confirming this are only visible if you provide a link to a debug log. -> https://wiki.libreelec.tv/support/log-files

If the HDMI handshake fails after a successful start with the same resolution, it indicates more for hardware issue like cheap/bad HDMI cabeling or firmware issues of devices. One of known trouble maker could be the Argon ONE case as well. If you use such case, please try again without that.

Maybe your HDMI cabeling makes additional issues (use certified cables with "Premium High Speed HDMI Cable with Ethernet" label at least to reach stable 18Gbps for 3840x2160@60Hz), because it appears the HDMI handshake is below of that - this could end with 30Hz like you described.

For troubleshooting purposes and your use case it could be better to capture the EDID data during a successfully working connection RPi5 + AVR + Beamer and save into a file to make it permanently.

getedid create https://wiki.libreelec.tv/configuration/edid#getedid-create

The created dump with the EDID data of your AVR + Beamer HDMI chain will be used at every boot instead of dynamic collecting this data. This way you avoid that the HDMI sink (Beamer) must be powered on during boot. The RPi5 relies on this information for proper display support. If something is changed on your cabeling ,like buying a new AVR/Beamer, afterwards you must delete the dump file with getedid delete and repeat this process. This also required if you change the used HDMI port at the AVR or Beamer.

PS: Please also make sure to use the preferred HDMI0/HDMI-A-1 port (nearest to the USB-C power connector).

Hi antonvier ,

it may not be directly related to your problem, but your power supply seems to be insufficient. You should try to fix that as the first step.

RPi throttled=0x50000
Feb 27 17:26:08.897568 LibreELEC kernel: hwmon hwmon0: Undervoltage detected!

Unfortunately, you have not yet answered whether this worked before.

It is to be expected that WAKE_ON_GPIO=2 consumes more power because a part must be active in order to monitor the GPIO. Have you tried WAKE_ON_GPIO=1 to see if it works? Is there any information about the purpose of the blue fan cable? Maybe you can use it to control/stop the fan just before shutdown. Because if the guys in the linked thread are right, the 5V rail stays on after shutdown.

EDIT:

There is different information about the GPIO pin to be used. GPIO14 may conflict with the serial console. Which pin are you currently using for the blue cable? And what does the content of your config.txt currently look like?

dtoverlay=gpio-fan,gpiopin=14,temp=80000

Did the fan function work before? I stumbled across this discussion:

How to boot and safely shutdown with a button when WAKE_ON_GPIO=0

1. Description To boot and shutdown my pi I have been using a button shorting GPIO 3 an GND. However after shutting down the pi, the fan shim and HDD keep on…

raspberrypi.stackexchange.com

It seems to depend on how the fan is connected and getting its power. What type of fan/HAT do you have? Can you give more details?

The behavior is expected, after some policy changes in new kernel version that only one consumer is allowed at the same time. GPIO3 seems to be blocked by your own script that you have started via autostart.sh, by another script/addon or an activated overlay in the config.txt that has been identified as ‘shutdown’. So you must terminate the process to free the resources in forehand. For debugging purposes of your running script you should be able to use the pinctrl command instead of gpioset to circiumstand the restriction.

pinctrl -p set GPIO3 pd

Regarding the switch-on issue, you should check and maybe change the current EEPROM settings. There could be some changes with recent firmware updates.

Quote

• Update halt behavior on Pi 400 to re-enable 'power on' button if the OS did a reset rather than using the standard mailbox shutdown commands. This overrides WAKE_ON_GPIO / POWER_OFF_ON_HALT settings on Pi 400 because it has a dedicated power button. If a button on GPIO3 really is requried then it can be re-enabled by setting WAKE_ON_GPIO=2 but that will consume more power.

Show current EEPROM settings:
vcgencmd bootloader_config

Edit EEPROM settings:
rpi-eeprom-config --edit

The HDMI0 port is the preferred one to also support 4K@60Hz (AFAIK: HDMI1 of the RPi4 supports max 4K@30Hz). With LE 12.0.1 there was an attempt to support CEC on both HDMI ports at the same time, but this caused more problems than it helped. This temporary function was dropped with LE 12.0.2.

Quote from hugosboss

Off-topic: This CEC issue also occurs with my stock Fire TV 4K stick.

Then it directs to an issue of your TV/Remote control/Cabling/AVR ... - not to KODI itself.

Background: The remote control signal is received by your TV and translated to CEC. If the translation is faulty, then it occurs at all devices do you trying to control. Sometimes a firmware update of the TV or AVR is required to fix that.

Common solution for typical CEC hiccups: Make all involved devices powerless at the same time for some minutes. This helps to reset the CEC settings.

I can see some possible culprits in your config.txt. But it could be, that you have a general issue with I2C currently.

It's a typo in the documentation of Argon40. If you want to force the PCIe speed to Gen 3, the line should show like this.

dtparam=pciex1_gen=3

For the troubleshooting purposes, please comment out the last 3 lines via a hashtag in your config.txt first:

#dtparam=i2c_arm=on
#dtparam=i2c_vc=on
#dtoverlay=i2c-bcm2708

Please don't forget to reboot after that changes, connect to LE via SSH and try the following:

• Stop KODI service
  systemctl stop kodi
• Check the current I2C state.
  i2cdetect -y 1

Please post the output of the i2cdetect command. If the address 0x1a isn't populated, make the case some seconds powerless (unplug the power supply) and try again afterwards.

EDIT: Your log looks like, that you have installed some banned components which are in conflict with the forum rules. Please do not expect any further support until you come back with a fresh install without such things.