Oh also the Enigma2 Client plugin does get disabled under LE 13 because it is incompatible. I suspect it's not actually incompatible, but just marked as such (or only marked to be compatible with LE 12). But that's a smaller secondary issue I noticed with LE 13, as the Pi mainly is used as a Jellyfin client and not for watching TV (that is done with the actual TV itself).
Posts by GamerBene19
-
-
I probably won't be able to try it out until Sunday,
I just got back, here's a quick update:
Hi,
Re PI / TV see 15227-tv-turns-on-by-itself it may help
Thanks! Turns out, I missed the second part (Devices to power on during startup) when I initially looked through the menu. Setting it to none did do the trick - the TV no longer turns on by itself.
I also tried out the latest nightly build (LibreELEC-RPi2.arm-13.0-nightly-20250426-07a8ef5). The update itself was successful, but I had to downgrade again, because even after multiple reboots the Pi unfortunately did not establish a WiFi connection (and the associated menu in the settings was just empty).I also did not have an Ethernet cable for SSH - or other means to open a terminal - at hand, so I wasn't able to diagnose the issue further. The only thing I saw was
CodeLibreELEC (community): nightly-20250426-07a8ef5 waiting on Network to come online... [FAILED] Failed to start network-online.service. [DEPEND] Dependency failed for openvpn.service.
during boot before Kodi started.
Note that both "the associated menu in the settings was just empty" and the above output during startup are usual symptoms under LE 12, when WiFi does not work. Usually it is fixed by a few reboots though - which did not seem to help with LE 13.
I have the same hardware (same Pi2 and WiFi Dongle) lying around somewhere. If I find them (and some time) I'll try to replicate the failing setup at (my) home for better debugging.
-
Download the relevant nightly file to /storage/.update
Is "the relevant nightly file" simply the latest img.gz from here? Also do I need to decompress it first?
I probably won't be able to try it out until Sunday, but I’ll let you know if anything changes (in regards to WiFi) once I do.
One thought/question: I am using the Estuary MOD V2 skin, do you happen to know if that breaks with LE 13?
I'll take a backup just to be sure, but it would be good to know beforehand if that skin will break.
While I have your attention: Is there a way to disable the connected TV from being controlled by the Pi via CEC? Currently the TV sometimes turns (and stays) on in the middle of the night, when the Pi reboots because of my script. I've looked into the settings of the CEC adapter addon, but perhaps I've not found the right knob yet.Thanks for all the help so far!
-
Start with updating to an LE13 nightly. There are newer versions of drivers and other wireless plumbing so the first step is to see if anything improves or changes.
Can I update directly from within LibreELEC without reinstalling?
If so: How?
If not: Should I just use the latest nightly image, or are there ones that are considered "more stable" than the others? I'd like to avoid introducing new/other issues if possible. -
I've set up LibreELEC 12.0.2 on a RaspberryPi 2B (which has no onboard WiFi) with a USB WiFi dongle (Edimax EW-7811Un) for my grandparents.
The Pi connects to a Jellyfin server via OpenVPN, and when it works, it works great - however it sadly does not work often as the WiFi connection frequently breaks.
Similar to other threads I experience the same "Invalid Key" error.
I've written (and continuously expanded) this script to check and fix the WiFi and VPN connection which gets executed every 5m via cron:
Bash
Display More#!/bin/bash # Get the current time timestamp() { date "+%Y-%m-%d %H:%M:%S" } # Path to the failure count file FAIL_COUNT_FILE="/tmp/wifi_fail_count" # Threshold when to reboot MAX_FAIL_COUNT=6 # Since the script is run every 5m, this corresponds to 30m # Read the current fail count (default to 0 if file doesn't exist) if [ -f "$FAIL_COUNT_FILE" ]; then FAIL_COUNT=$(cat "$FAIL_COUNT_FILE") else FAIL_COUNT=0 fi # Debug output of connmanctl services echo "$(timestamp) - Current connman services:" connmanctl services # Check if the Wi-Fi is connected using connman if ! connmanctl services | grep -q "\*AR"; then echo "$(timestamp) - Wi-Fi is down. Attempting to reconnect..." # Perform a Wi-Fi scan echo "$(timestamp) - Scanning for available Wi-Fi networks..." connmanctl scan wifi sleep 5 # Allow time for scan to complete echo "$(timestamp) - Available Wi-Fi networks:" connmanctl services # Restart the network service systemctl restart connman # Wait a few seconds to allow reconnection sleep 10 # Check again if connected if connmanctl services | grep -q "\*AR"; then echo "$(timestamp) - Wi-Fi reconnected successfully." echo 0 > "$FAIL_COUNT_FILE" # Reset counter else echo "$(timestamp) - Failed to reconnect Wi-Fi. Exiting." FAIL_COUNT=$((FAIL_COUNT + 1)) echo "$FAIL_COUNT" > "$FAIL_COUNT_FILE" echo "$(timestamp) - Failure count: $FAIL_COUNT" if [ "$FAIL_COUNT" -ge "$MAX_FAIL_COUNT" ]; then echo "$(timestamp) - Reached $MAX_FAIL_COUNT failed attempts. Rebooting..." systemctl reboot fi exit 1 fi else echo "$(timestamp) - Wi-Fi is already connected." echo 0 > "$FAIL_COUNT_FILE" # Reset counter fi # Check if the VPN is working echo "$(timestamp) - Checking VPN connection..." VPN_TEST_URL="https://jellyfin.url.some.tld" curl -L --silent --fail $VPN_TEST_URL > /dev/null if [ $? -ne 0 ]; then echo "$(timestamp) - VPN connection is down. Restarting VPN..." # Reconnect VPN systemctl stop openvpn script_type=down /storage/.config/openvpn/update-nameservers.sh systemctl start openvpn # Wait for VPN to reconnect sleep 30 # Recheck VPN connection curl -L --silent --fail $VPN_TEST_URL > /dev/null if [ $? -ne 0 ]; then echo "$(timestamp) - VPN reconnection failed." else echo "$(timestamp) - VPN reconnected successfully." fi else echo "$(timestamp) - VPN is working correctly." fi
The output of that looks something like this (in the most extreme cases)
Code
Display More2025-04-09 12:50:00 - Current connman services: *AR <TARGET-WIFI> wifi_74da386e443b_..._managed_psk Some wifi_74da386e443b_..._managed_psk Other wifi_74da386e443b_..._managed_psk Unrelated wifi_74da386e443b_..._managed_psk WiFi wifi_74da386e443b_..._managed_psk Networks wifi_74da386e443b_..._managed_psk From wifi_74da386e443b_..._managed_psk Random wifi_74da386e443b_..._managed_psk Neighbours wifi_74da386e443b_..._managed_psk 2025-04-09 12:50:00 - Wi-Fi is already connected. 2025-04-09 12:50:00 - Checking VPN connection... 2025-04-09 12:50:00 - VPN is working correctly. 2025-04-09 12:55:00 - Current connman services: WiFi wifi_74da386e443b_..._managed_psk From wifi_74da386e443b_..._managed_psk Random wifi_74da386e443b_..._managed_psk 2025-04-09 12:55:00 - Wi-Fi is down. Attempting to reconnect... 2025-04-09 12:55:00 - Scanning for available Wi-Fi networks... Scan completed for wifi 2025-04-09 12:55:07 - Available Wi-Fi networks: 2025-04-09 12:55:17 - Failed to reconnect Wi-Fi. Exiting. 2025-04-09 12:55:17 - Failure count: 1 2025-04-09 13:00:00 - Current connman services: 2025-04-09 13:00:00 - Wi-Fi is down. Attempting to reconnect... 2025-04-09 13:00:00 - Scanning for available Wi-Fi networks... Scan completed for wifi 2025-04-09 13:00:07 - Available Wi-Fi networks: 2025-04-09 13:00:17 - Failed to reconnect Wi-Fi. Exiting. 2025-04-09 13:00:17 - Failure count: 2 2025-04-09 13:05:00 - Current connman services: 2025-04-09 13:05:00 - Wi-Fi is down. Attempting to reconnect... 2025-04-09 13:05:00 - Scanning for available Wi-Fi networks... Scan completed for wifi 2025-04-09 13:05:07 - Available Wi-Fi networks: 2025-04-09 13:05:17 - Failed to reconnect Wi-Fi. Exiting. 2025-04-09 13:05:17 - Failure count: 3 2025-04-09 13:10:00 - Current connman services: 2025-04-09 13:10:00 - Wi-Fi is down. Attempting to reconnect... 2025-04-09 13:10:00 - Scanning for available Wi-Fi networks... Scan completed for wifi 2025-04-09 13:10:07 - Available Wi-Fi networks: 2025-04-09 13:10:17 - Failed to reconnect Wi-Fi. Exiting. 2025-04-09 13:10:17 - Failure count: 4 2025-04-09 13:15:00 - Current connman services: 2025-04-09 13:15:00 - Wi-Fi is down. Attempting to reconnect... 2025-04-09 13:15:00 - Scanning for available Wi-Fi networks... Scan completed for wifi 2025-04-09 13:15:07 - Available Wi-Fi networks: 2025-04-09 13:15:17 - Failed to reconnect Wi-Fi. Exiting. 2025-04-09 13:15:17 - Failure count: 5 2025-04-09 13:20:00 - Current connman services: 2025-04-09 13:20:00 - Wi-Fi is down. Attempting to reconnect... 2025-04-09 13:20:00 - Scanning for available Wi-Fi networks... Scan completed for wifi 2025-04-09 13:20:07 - Available Wi-Fi networks: 2025-04-09 13:20:17 - Failed to reconnect Wi-Fi. Exiting. 2025-04-09 13:20:17 - Failure count: 6 2025-04-09 13:20:17 - Reached 6 failed attempts. Rebooting... 2025-04-09 13:25:00 - Current connman services: *AR <TARGET-WIFI> wifi_74da386e443b_..._managed_psk Some wifi_74da386e443b_..._managed_psk Other wifi_74da386e443b_..._managed_psk Unrelated wifi_74da386e443b_..._managed_psk WiFi wifi_74da386e443b_..._managed_psk Networks wifi_74da386e443b_..._managed_psk From wifi_74da386e443b_..._managed_psk Random wifi_74da386e443b_..._managed_psk Neighbours wifi_74da386e443b_..._managed_psk Now wifi_74da386e443b_..._managed_psk More wifi_74da386e443b_..._managed_psk 2025-04-09 13:25:00 - Wi-Fi is already connected.
As you can see, connmanctl scan wifi and a subsequent systemctl restart connman do not always fix the issue, only rebooting does in this case.
I've also seen various mentions about this issue being related to poor reception (with the suggestion to use a USB dongle - which I already do) and that moving the WiFi client closer to the access point helped. While I don't want to dismiss that outright, I am rather skeptical that this is (purely) related to range/reception issues because I've seen all of below:
- when the connection is present the dB value is "good" and it's fast enough to stream HD movies (~30 Mbit/s in my case)
- sometimes suddenly no WiFi networks are found and 5-10m later everything is back to normal
- sometimes WiFi networks from further away are found, but not the closer "target WiFI"
- no other clients experience connection issues
- mentions of it working in previous LE versions (where wpa_supplicant was used)
- mentions of the same hardware working fine under RaspberryPi OS (and others)
I've found that in another thread iwctl was used to do the reconnect. Is there any (significant) difference between the iwctl and connmanctl?
Is there anything I can (still) do to improve the WiFi reliability except for buying something like this?
For now I am looking for a quickish solution to make my grandparents happy, but in the long run I am eager to help debug/improve the issue. Although I think it makes more sense to continue this thread instead.
Thanks in advance for all the help!