Regarding "libreelec configuration error.", it contains no information which kind of error occurs. The usual way to report errors is:
- Enable debug logging
- Reboot
- Reproduce the issue
- Paste the log and provide the URL afterwards
Regarding "libreelec configuration error.", it contains no information which kind of error occurs. The usual way to report errors is:
Within KODI. The menu path is: Settings(gear wheel) -> Services -> UPnP/DLNA
Do you have an LG TV and does that also happen if you disable UPnP?
Version 1.1.10 released:
This should fixes the issue reported by Gwin. The PRs have been created to provide this version via LibreELEC add-ons repo as well.
I was able to find 2 possible causes for the reported switch-off problem. Both situations can be prevented/fixed if the settings dialogue of the add-on has been closed once with OK (this will create/update the required settings.xml). I will provide an updated version of the add-on to fix the problem permanently.
Perhaps I should take another look at this. The shutdown script expects the setting value (false/true) to be present. There may be an edge case that I didn't stumble across in my tests.
EDIT:
I assume you had a previous version already installed and updated to 1.1.9. Can you remember your workflow? Did you have opened the add-on settings afterwards and left the menu with OK at least once, before you observed the failing shutdown?
Has anyone else observed the same misbehavior?
Gwin,
thank you for the feedback. This should only happen if "Activate compatibility mode for ONE V1" is enabled, as this disables V3 support as described in the help text. Did you activate this by mistake?
The add-on is now also available for LE12 via the LibreELEC add-ons repo. It was automatically updated in the background, although it was previously a manually installed version 1.1.9. This happened shortly after the start without a confirmation dialogue appearing.
It was showing in the log that it was 1.1.9 during KODI startup but I couldn't reproduce that situation afterwards, maybe depends on the refresh of the repo inventory. This behaviour was unexpected, but it seems a good working mechanism.
Version 1.1.9 released:
It would be nice if someone could test with a V1 case whether the effort for this switch was worthwhile and now helps to achieve a functioning fan control or whether it is useless.
Version 1.1.8 released:
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:
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.