If you want support from experienced users or from experts like chewitt , you shouldn't skim with information. Snippets of logs are in 99.99 percent are pointless and and results into same as if you post "something is going wrong" - nothing more, no helpful content. Please provide a full debug log like described above.
Posts by HarryH
-
-
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
-
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?
PostRE: Persistent Hourly Restart Issue on Raspberry Pi 4 with LibreELEC
The crash is from:
(Code, 5 lines)
PLT seems to be a uPnP library, so you could try disabling it in system/services/UPnP/DLNApopcornmixApril 24, 2024 at 2:56 PM -
Version 1.1.10 released:
- regression: shutdown does not work properly if the settings.xml file is incomplete or missing
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:
- compatibility: some early MCU firmware versions could hang off after register support check
- added menu option to explicitly disable register support detection for ONE V1/Fan HAT
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:
- 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.
- 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.
-
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.