Just install from the repo over the top of the existing add-on and then future updates from the repo will auto-update things.
The LE13 addon is now merged. Let's see if all is okay and then we'll merge to LE12 too.
Posts by chewitt
-
-
Run "dmesg | paste" and share the URL so we can see the full log. Always share a full log; every time you share log snippets you are leaving out useful info/context on the device.
-
but UI is crap and I want to get Kodi on there instead
So why not install Kodi on Android?
-
Please update with: https://chewitt.libreelec.tv/testing/LibreE…_64-12.80.0.tar - the image now uses Linux 6.14.0 which contains a load more r8169 changes. If that works i'll revert back to 6.12.x and the extra patch that smp flagged. I'd already built the 6.14 image so you might as well test that first.
-
I am not attempting to install LibreELEC
Then you are in the wrong forum. We support LibreELEC not Android. We do not collect/share Android ROMs.
-
The 2GB is enough for normal LE use. If you want to run additional services in the background (docker, tvheadend, etc.) the 4GB or 8GB variants would be more suitable. The eeprom option POWER_OFF_ON_HALT=1 is not configured in LE by default, but you can change that yourself if desired.
-
Are you attempting to install LibreELEC or trying to load a new Android ROM?
-
LibreELEC supports custom alsa routing configuration via /storage/.config/asound.conf so on an OS level there is nothing to prevent you from configuring the audio hardware to route audio from the S/PDIF input to the speakers. However it cannot be done from the Kodi UI as there is simply no concept of audio input (only output) within Kodi.
The next challenge is that alsa configuration and routing is one of the Linux "dark arts" and the configuration you seek is specific to that exact hardware so there is rarely some kind of 'generic' solution or example to follow, and nobody here is an alsa expert, and Google searching for alsa configuration normally returns a million irrelevant results; it's a particularly dense and troublesome topic to search and find useful information on.
As we are unlikely to be helpful and you have nothing to lose; Give ChatGPT or GitHub Copilot examples of amixer controls and amixer contents output and some prompt/direction and ask them to suggest an asound.conf. I have low expectations of anything they create actually working, but it might give you hints for further research.
-
If the subtitle add-on is available from the Kodi repo then it's fine to mention here. Are there any others?
-
I linked the .tar file because you said WiFi worked so you have a working internet connection. I assume this was used to share the previous "dmesg | paste" dump. An .img.gz version of the tweaked image is in the same webserver folder but reinstalling only results in the same state as an update (which is quicker/easier).
Please share a URL from "dmesg | paste" again, so we can see if the chip is now correctly detected and is there any attempt to load firmware? Note that r8169.ko.xz is an xz compressed kernel module (.ko) file not firmware (usually .bin or .fw) so adding that to the image via a firmware overlay will not do anything useful.
-
I'm not sure why it's not working in LE12, but it isn't, and we're unlikely to release more LE12 maintenance updates, so:
Kodi 22 (Piers) removes support for setting the timezone from within Kodi (as this is an OS function) so LE13 nightly images now set timezone from the LE settings add-on, and this definitely works. So the workaround is to update to an LE13 nightly.
-
Pinging this thread to raise awareness of new WireGuard capabilities that need testing:
-
Pinging this thread to raise awareness of new WireGuard capabilities that need testing:
-
Pinging this thread to raise awareness of new WireGuard capabilities that need testing:
-
Pinging this thread to raise awareness of new WireGuard capabilities that need testing:
-
Pinging this thread to raise awareness of new WireGuard capabilities that need testing:
-
Pinging this thread to raise awareness of new WireGuard capabilities that need testing:
-
Regular ConnMan contributor and SailfishOS maintainer Jussi Laakonen has been working on improvements to WireGuard support in ConnMan. Specifically, the ability to define 'Host' (the remote WireGuard server) as a hostname/FQDN instead of an IP address. This eases long-term WireGuard use with servers self-hosted from dynamic IP address ranges, and commercial WireGuard services where each node has multiple IP addresses in DNS that are rotated reguarly to avoid IP blocking. The changes should also perform periodic re-resolving of the connection hostname to ensure connectivity is maintained when an IP changes. However, I can't test that as my own WireGuard server is on a static address, so we'd like to crowdsource some further testing
The following image for RPi5 contains the changes:
RPi5: https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.0.tar
To test, update to the test image then edit your WireGuard .config file to define 'Host' with a hostname/FQDN then reboot. On reboot check the WireGuard connection is up and that traffic is routed down the tunnel by running curl icanhazip.com .. it should return the WAN address of the remote side.
For reference, Jussi's changes can be seen here: https://github.com/LaakkonenJussi…pn_association/ and I've build the LE image with this change: https://github.com/chewitt/LibreE…0a2da07a27919da.
EDIT, the RPi5 image in my test share will be updated as other changes/refinements are made to Jussi's codebase upstream. You will need to check commits in https://github.com/chewitt/LibreELEC.tv/commits/rpi-13.0 for latest githash/changes to build with LE.
