Posts by Doemela

Quote from Reddirt

7/31
LE 13.0 Pi5 20260729 nightly v1.5.2~rc.3
https://paste.libreelec.tv/matter-pasty.log
Running smooth here. I see it shows an error but did not notice anything as user. Maybe a homotron.

That was former version so np:
2026-07-29 15:02:36.131 T:1059 error <general>: service.wireguard.manager v1.5.2~rc.1: Service Launcher: Verification loop aborted. Network target down.

Thanks.

Hello Brun0 ,

Because you are running on a non-Raspberry Pi wireless setup, your hardware requires slightly more time to cleanly tear down existing connection profiles when switching locations. Because the connection processing occasionally takes slightly longer than the hard-coded limits of the previous build, it caused a timeout crash. This left a stale .lock state file behind, which blocked your TV channels (PVR) and locked down your local routing parameters (disrupting SSH/Samba access).

Please install the updated script modules https://github.com/BrodjagaRatnik…-1.5.2~RC.3.zip and let me know if everything is running smoothly!

Best regards, Doemela.

Quote from Reddirt

Maybe try the latest version 1.5.2~rc

Reddirt You beat moi you can also test https://github.com/BrodjagaRatnik…-1.5.2~RC.3.zip specially on that I7.

v1.5.2 (2026-08-0?)
- Fixed: Resolved an exit status 22 argument error on Wi-Fi profile swaps.
- Fixed: Prevented system lockouts and file tracking freezes on slower hardware tiers.
- Optimized: Maintained local subnets and gateway paths to guarantee uninterrupted SSH/Samba access.
- Fixed: Resolved an exception routing conflict where upstream HTTP 429 server blocks returned empty token responses.
- Fixed: Resolved an issue causing the exception tree to misinterpret events and erroneously trigger the 401 alert window.
- Optimized: Implemented dynamic file state inspection within the token verification routine to accurately isolate locks.
- Optimized: Prioritized system rate-limiting locks over authentication validation screens during active profile swaps.

Salute.

Thank you so much for testing the beta build and sharing the logs!

I can see from the entries that the connection teardown and the dynamic DNS recycling are now working flawlessly. The stream links (pvr.iptvsimple) are resolving instantly and cleanly right after the tunnel closes without hitting any deadlocks.

The fix is officially successful! Thank you again for your time, and have a wonderful weekend as well!

Brun0

I have built a specific test build to automate this fix directly inside the add-on logic. This will proactively catch and repair the ConnMan DNS deadlock on your system during execution.

You can download and install the update from here: service.wireguard.manager-1.5.1~beta.zip

What this update does:
Every time a VPN disconnection occurs, the manager now performs an internal DNS deadlock. If it detects that ConnMan has left your network in an unresolvable state (triggering the ifconfig.co error), it automatically triggers a fallback routine to flush the stale cache and force ConnMan to dynamically pull your local router's original DNS settings via DHCP. If a static IP is set, the script only clears the manual DNS block, causing ConnMan to immediately fall back to the manual DNS entered in LibreELEC, without affecting the static IP configuration.

Please install this beta build, test your add-on switching workflow, and let me know if your TV channels and the pastebinit log uploader function correctly without any manual terminal commands.

Salute.

The Could not resolve host: ifconfig.co error confirms that your system is experiencing a DNS deadlock after switching add-ons, meaning LibreELEC's network manager (ConnMan) is failing to restore your local router's DNS servers.

Since this issue does not occur for other users, it is likely caused by a local configuration conflict or a static IP setup on your device.

To fix this and get your TV channels back immediately without rebooting, you can manually force a working DNS server via SSH using ConnMan. Please follow these steps:

1. Connect to your LibreELEC device via SSH.

2. Run the following command to find your active network service ID:

  connmanctl services

(Look for the line starting with *AO or *AR which represents your active Ethernet or Wi-Fi connection. Copy the long ID string at the end of that line, it will look like ethernet_b0d5cc... or wifi_2ccf67...)

3. Run this command to force assign public DNS servers to your connection (replace <your_service_id> with the ID you just copied):

  connmanctl config <your_service_id> --nameservers 1.1.1.1,8.8.8.8

Once executed, your internet connectivity, TV channels, and the pastebinit log uploader should work instantly.

A quick question to help prevent this from happening again: Do you have a manual/static IP address configured in your LibreELEC network settings, or do you use any other VPN/IPTV management add-ons on this system?

I see in your rollable-sherice log:
requests.exceptions.HTTPError: 422 Client Error: Unprocessable Entity for url: https://k7.ftven.fr/videos/006194e…a9-153d999c59ae?country_code=NL&capabilities=drm&os=androidtv&diffusion_mode=tunnel_first&offline=false

You either not connected to a French VPN server or the video plugin uses cache and NL is in the cache (so remove cache from that addon). For mapping video plugin -> VPN-country you do not have to use it you can also do:

1. Connect to the desired VPN country server.
2. Start/stream the addon.

🗺 4. VPN Mapping (The Priority System)

This automated tool pairs specific VPN locations directly to individual Kodi video add-ons. If you do not pair your chosen add-on app to a specific server location no connection will be made.

Salute.

Quote from Brun0

Please i need help,

I configured my config file (Proton VPN), but when I import and start the service manager, I get this error message: "error <general>: service.wireguard.manager v1.4.9: VPN Connector: VPN connection, handshake failed. Handshake failed. Refused, rate-limited, or unreachable."

I can't seem to find where the problem is.

Provide the wireguard config file(s) please no privatekey. Did you read https://github.com/BrodjagaRatnik…via-Custom-Mode

Set kodi in debug logging and copy/paste this in ssh:

grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log | pastebinit

Or provide a full debug log.

How to post a log (wiki)

1. Enable debugging in Settings>System Settings>Logging
2. Restart Kodi
3. Replicate the problem
4. Generate a log URL (do not post/upload logs to the forum)

use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

Unplug and replug the DAC, then immediately run this command:

lsusb -d 0d8c:0012 -v

The proposed Kodi pull request (PR) will not fix the underlying issue or change the standard for good python coding; it merely changes how Kodi handles and reports the developer's errors. The PR modifies CPythonInvoker to forcefully run a garbage collection cycle and clear module dictionaries before tearing down the Python sub-interpreter. While this prevents Kodi from crashing (segmentation fault) or spamming logs during a profile switch, it is an application-level safety net. It does not absolve the addon developer from writing clean code.

The PR cleans up the leaked memory only when the execution is completely finished or when switching profiles. If an addon leaks xbmc.Monitor or xbmc.Player objects during its normal runtime execution (e.g., repeatedly restarting a background service or script without destroying old instances), those objects will still consume RAM and leak resources until the entire interpreter environment is destroyed.

In short, the PR fixes Kodi's stability when handling badly written addons, but good conduct Python coding still dictates that developers must explicitly close monitors, stop players, and avoid circular references in threads to prevent active runtime memory leaks.

Salute.

Think we haxored it Following up on my previous report regarding the severe file descriptor leak in connmand when using WireGuard (wg0) tunnels, my team and testers have successfully isolated the root causes and implemented a elegant solution, zero-leak workaround. It turns out there were two separate upstream tracking bugs inside ConnMan's older network cache layer that trigger when an out-of-band virtual interface alters default routing metrics.

• ConnMan's internal DNS proxy layer loops indefinitely trying to process client sockets during interface state changes, leaking 10 FDs every minute.
• ConnMan constantly polls ipv4.connman.net to verify global internet status. When WireGuard routes shift mid-flight, these TCP connections get permanently orphaned in a CLOSE_WAIT state, trickling in an additional 2–3 leaks per minute on older environments (like LibreELEC 12).

By completely disabling ConnMan's internal DNS proxy and turning off its aggressive global connectivity tracking, the daemon relies on native Linux routing. This drops the file descriptor load down to baseline and completely flatlines the leak. Here is the exact setup we deployed via SSH to fix the issue:

Open or create /storage/.config/connman_main.conf and ensure the online check is completely disabled:

[General]
EnableOnlineCheck = false

To apply your changes and restart ConnMan via SSH, use this command:

systemctl daemon-reload && systemctl restart connman

Create the service drop-in override directory and force ConnMan to start with the --nodnsproxy flag active:

mkdir -p /storage/.config/system.d/connman.service.d
cat << 'EOF' > /storage/.config/system.d/connman.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -nr --config=/storage/.config/connman_main.conf --nodnsproxy
EOF

Reload and Apply in ssh:

systemctl daemon-reload
systemctl restart connman

Verification:

watch -n 1 "echo -n 'VPN Daemon (connman-vpnd): '; ls -l /proc/\$(pidof connman-vpnd)/fd 2>/dev/null | wc -l; echo -n 'Main Daemon (connmand):    '; ls -l /proc/\$(pidof connmand)/fd 2>/dev/null | wc -l"

LibreELEC 13 (Generic): File descriptors stay perfectly locked and flat at 30 FDs. LibreELEC 12 (Pi4 / Pi5): File descriptors stay perfectly locked and flat at 22 FDs without a single trickle over time. The system is now completely stable. I have forwarded these exact details to the ConnMan upstream developer mailing list ([email protected]) so they can investigate adding proper close() descriptors inside the rtnl or proxy source arrays for future releases.

Salute.

Thank you for checking the patch history. I have followed your advice and officially submitted a detailed bug report upstream to the ConnMan developers mailing list. For anyone else running into this freeze or loop while using WireGuard configurations, here is a summary of what I have discovered and how I have managed to mitigate the issue in the meantime:

When an out-of-band WireGuard interface changes the system routing table, ConnMan's internal DNS proxy subsystem gets caught in a loop. It repeatedly spawns client sockets targeting the gateway (port 53), but fails to run a close() system call on them. These orphaned file descriptors accumulate rapidly until they hit the Linux process limit of 1024. Once hit, all network resolutions fail and the system freezes. On LibreELEC 13 (Generic), the socket leak is completely tied to the DNS proxy loop. On LibreELEC 12.2.1 (Pi4, PI5), an older tracking bug remains active alongside the DNS loop, trickling in an additional 2 unclosed anonymous sockets per minute during active VPN cycles.

Bypassed ConnMan's broken DNS proxy layer by applying a custom systemd runtime override flag. This forces the OS to handle DNS calls natively without letting ConnMan drop handles. If your system is freezing due to this leak, you can apply this workaround via SSH:

mkdir -p /storage/.config/system.d/connman.service.d
cat << 'EOF' > /storage/.config/system.d/connman.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -nr --config=/storage/.config/connman_main.conf --nodnsproxy
EOF
systemctl daemon-reload
systemctl restart connman

On LE 13 the file descriptor count stays completely flat and stable (locked around 30 FDs), entirely fixing the crash. On LE 12 the massive socket storm is blocked, slowing the leak down drastically to just 2 FDs per minute, giving the machine significantly longer uptime before needing a network service restart. Hopefully, the upstream developers can pinpoint exactly where the missing close() descriptors are in the rtnl or proxy source arrays.

Salute.

Quote from jbinkley60

This was an issue a couple of years ago, got fixed and seems to have crept back beginning with the June 6th nightly build. The issue is where with LibreElec (generic version on Intel), not with Kodi on Windows, that many addons, including the LibreElec configuration addon are spewing classes left in memory errors. This is likely due to a problem with the Python garbage collection process. A thread was started in the Kodi forum. I just wanted to raise it here, in case the developers were unaware. I had posted some logs there but this is very easy to reproduce.

Thanks,

Jeff

When a Kodi addon stops or restarts, Python must properly clean up all used Kodi API classes. If an addon developer forgets to close or disconnect specific objects, these objects remain permanently in the devices' RAM. Kodi then displays this exact "has left several classes in memory" warning. These are pure Python memory leaks within the Kodi application itself, having nothing to do with core LibreELEC or Kodi. These warnings are almost always caused by two specific programming errors:

1. Unclosed Monitors/Players: The developer uses xbmc.Monitor or xbmc.Player but forgets to delete it when the addon stops.
2. Circular References: A global reference to the xbmcaddon.Addon() object persists in a background thread that has not been closed correctly.

I have isolated a severe file descriptor resource leak in ConnMan (connmand) that affects both LibreELEC 12 (RPi4/RPi5) and LibreELEC 13 (Generic/x86_64). When an addon or binary initializes an unmanaged, kernel-space WireGuard tunnel (wg0) directly via kernel interfaces, ConnMan's rtnl (Route Netlink) subsystem monitors the link changes but fails to release its internal tracking sockets. The file descriptors tick up steadily at about 5 FDs every 2 minutes until they hit the Linux operating system kernel ceiling of 1024 total FDs.

Once it reaches 1025 FDs, ConnMan throws a Too many open files error and crashes completely. Because LibreELEC depends entirely on ConnMan for networking, this crash drops all system IP routes, instantly dropping active SSH sessions and killing local network connectivity until a hard physical power cycle is performed. Conman Problem

Steps to Reproduce

1. Manually initialize or cycle a standard kernel-space WireGuard interface (wg0) outside of ConnMan's limited D-Bus infrastructure.
2. Track the file descriptor handle counts of the daemon over SSH:

watch -n 1 "ls -l /proc/\$(pidof connmand)/fd | wc -l"

Watch the baseline count steadily climb past 500, hitting the 1025 wall within 2–3 hours, resulting in a total network drop.

LibreELEC 12.2.1 (Pi5 system hitting the 1024 ceiling and dropping connection):

2026-07-19 17:56:00.000 info <general>: service.connman.monitor v1.0.0: Connman profile -> Sockets: 1015 | Total FDs: 1025 | VPND FDs: 10
2026-07-19 17:57:00.000 info <general>: service.connman.monitor v1.0.0: Connman profile -> Sockets: 1015 | Total FDs: 1025 | VPND FDs: 10
client_loop: send disconnect: Connection reset
ssh: connect to host 192.168.178.45 port 22: Connection timed out

LibreELEC 13 (Generic Test confirming the exact same leak profile remains active upstream):

2026-07-20 01:56:14.938 T:1313 info <general>: service.wireguard.manager v1.5.0~beta: Wm Utils: Connman socket leak detected (514/526 FDs). VPN is disconnected. Executing safe background network reclamation...

System Details:

• LibreELEC Versions Tested: 12.2.1 / LibreELEC-Generic.x86_64-13.0-nightly-20260719-3d3de99
• Hardware Tested: Raspberry Pi 4, Raspberry Pi 5, Generic x86_64.
• Workaround: I have had to write an addon script that intercepts the leak when the VPN is disconnected and safely calls an atomic background systemctl restart connman script loop to prevent hard crashes.

Has anyone else encountered this socket aggregation issue with custom virtual interfaces, or is there an upstream ConnMan patch planned to improve netlink garbage collection?

#!/bin/sh
<<'COMMENT'

chmod +x /storage/.config/scripts/service.connman.monitor.sh
crontab -e
* * * * * /storage/.config/scripts/service.connman.monitor.sh
tail -f /storage/.kodi/temp/kodi.log | grep -iE "service.connman.monitor"

COMMENT
LOG_FILE="/storage/.kodi/temp/kodi.log"
TAG="service.connman.monitor"
VERSION="v1.0.0"
PID_CONNMAN=$(pidof connmand)
PID_VPND=$(pidof connman-vpnd)

if [ -z "$PID_CONNMAN" ]; then
    TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S.000")
    echo "${TIMESTAMP} error <general>: ${TAG} ${VERSION}: Internal exception during connmand socket monitoring: connmand is not running!" >> "$LOG_FILE"
    exit 1
fi

FD_TOTAL=$(ls -l /proc/"$PID_CONNMAN"/fd 2>/dev/null | wc -l)
FD_SOCKETS=$(ls -l /proc/"$PID_CONNMAN"/fd 2>/dev/null | grep -c "socket:")

if [ -n "$PID_VPND" ]; then
    FD_VPND=$(ls -l /proc/"$PID_VPND"/fd 2>/dev/null | wc -l)
else
    FD_VPND="0"
fi

TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S.000")

echo "${TIMESTAMP} info <general>: ${TAG} ${VERSION}: Connman profile -> Sockets: ${FD_SOCKETS} | Total FDs: ${FD_TOTAL} | VPND FDs: ${FD_VPND}" >> "$LOG_FILE"

2026-07-19 23:41:20.626 T:213859    info <general>: service.wireguard.manager v1.5.0~beta: Service Launcher: Hardware timings loaded for Raspberry Pi 5
2026-07-19 23:41:20.632 T:213859    info <general>: service.wireguard.manager v1.5.0~beta: Service Launcher: Monitor Service Initialized & Ready
2026-07-20 01:46:06.397 T:213859    info <general>: service.wireguard.manager v1.5.0~beta: Wm Utils: Connman socket leak detected (502/514 FDs). VPN disconnected. Executing safe background network reclamation...

https://paste.libreelec.tv/olivary-leonard.log

2026-07-20 02:06:56.078 T:756983    info <general>: service.wireguard.manager v1.5.0~beta: Service Launcher: Hardware timings loaded for Raspberry Pi 4
2026-07-20 02:06:56.090 T:756983    info <general>: service.wireguard.manager v1.5.0~beta: Service Launcher: Monitor Service Initialized & Ready

https://paste.libreelec.tv/mistiest-yung.log

LibreELEC-Generic-13

https://paste.libreelec.tv/englacial-brynlee.log

https://paste.libreelec.tv/antiempirical-samuel.log

Hi fizix ,

To make sure everything works perfectly for your setup, there are two important things to clarify regarding how this add-on operates and how it handles local network traffic.

1. Platform compatibility

Please note that this add-on is a LibreELEC-exclusive service. It is built specifically to interact with connmanctl (the native network manager in LibreELEC/Linux).

• It cannot be installed or run on Windows or iOS.
• For your Windows and iOS clients, you will need to continue using the official, native WireGuard applications to manage those connections. This manager is strictly for the LibreELEC machine itself.

2. Local LAN access (Kodi Remote & SSH)

You do not need to worry about losing access to your Kodi Remote app or SSH when activating the VPN on LibreELEC. Even if your configuration uses AllowedIPs = 0.0.0.0/0 (tunneling all internet traffic through the VPN), the underlying Linux kernel and ConnMan automatically maintain an implicit route for the directly connected subnet (your physical Ethernet or Wi-Fi connection).

As long as your iOS device (running the remote app) and your Windows PC (running SSH) are on the same local network as the LibreELEC machine at your remote location, they will always retain full access to it. The local traffic will bypass the VPN tunnel automatically.

Salute.

Perfect. I'm much better at connecting with humans than trying to talk dirty to a mainframe anyway!

Quote from Alucard van Blood

Dang! Took longer than I expected until someone suggests to try "fresh install" or something like that
For the moment I do not have the time to start something from scratch, but I'll keep it in mind...

Concerning VPN:

1. I tested it with the addon _deactivated_, but that did not fix anything, thus I reactivated it.
2. I know that the latest version of the addon is over 3 years old. Maybe I should give the WireGuard addon a try...
   Does not support Proton... Any suggestions?

You can use any WireGuard client that also matches official specifications to connect to Proton VPN servers using WireGuard. https://github.com/BrodjagaRatnik…via-Custom-Mode If you have any problems you can always ask me.

No problem, thank you for double-checking and clearing that up!

The sudden cutoff at the end point points toward a hardware-level crash (like a voltage drop from the power supply when the heavy skin loads artwork, a thermal cutoff or corrupt sd).

Salute.

The forum moderator's automated scanner triggered a "false positive" on your log.

Your log contains "repository.titan.bingie.mod", which is a completely legal cosmetic skin repository used to make the Kodi menus look like Netflix. It does not provide any illegal piracy streams or copyright-infringing content.

However, you are denied support for any file containing the word "titan" because it shares a name with "Mad Titan Sports"—a completely unrelated, blacklisted piracy add-on. The moderator simply saw the word "titan" in your repository list and closed the thread based on that keyword match. @Mayoru's entire crash log is 100% clean. There isn't a single illegal streaming app or piracy add-on in it.