Posts by Doemela

    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:

    Code
    [General]
    EnableOnlineCheck = false

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

    Shell session
    systemctl daemon-reload && systemctl restart connman

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

    Shell session
    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:

    Shell session
    systemctl daemon-reload
    systemctl restart connman

    Verification:

    Shell session
    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:

    Bash
    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.

    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:
    Shell session
    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):

    Code
    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):

    Code
    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?


    Code
    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

    Code
    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.

    Dang! Took longer than I expected until someone suggests to try "fresh install" or something like that :P
    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.

    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.

    You can take a few steps yourself to check if the blockade is being imposed by the Russian government:

    1. Use official Russian verification tools: The Russian telecom watchdog Roskomnadzor has a public database. You can enter a URL or IP address on their official website (blocklist.gov.ru https://blocklist.rkn.gov.ru https://eais.rkn.gov.ru/en/ https://help.orionnet.ru/page28734115.html https://2ip.io/rkn-blacklist/ https://www.experte.com/internet-censorship/russia) to see if it is officially on the blacklist.
    2. Use OONI Probe: This is a free, global network that measures internet censorship. You can use their app or website to check if specific websites or apps are currently being blocked in Russia via DPI techniques. https://ooni.org/
    3. Test with a VPN (outside Russia): If you are in Russia and a website does not load, turn on a good VPN that connects to a server in the Netherlands, Germany, ... . Does the website load now? Then the Russian firewall is blocking it.

    View the error code:

    • Are you getting a Connection Timed Out? This often indicates a firewall that is silently dropping the traffic.
    • Are you getting a specific HTTP 451 error code? This literally means: "Unavailable for legal reasons".

    The problems with the LibreELEC repository at the Russian provider Greenwave are almost certainly caused by government DPI (Deep Packet Inspection), which acts as a 'firewall' that slows down or blocks traffic to the LibreELEC server. Since the outage disappears when using a VPN, such as Cloudflare WARP, the connection to the German hosting provider Hetzner is likely being cut off by automatic filters. A structural solution is to permanently enable a VPN or anti-censorship tool to bypass the firewall.

    I checkt it. The IP address in question is 116.203.139.247. This is the server for addons.libreelec.tv. The server is located at Hetzner (Germany).

    The "Silent" Blockade via the TSCP system:

    If you enter this IP address on the official site blocklist.rkn.gov.ru, chances are that no official blockade will appear. This is because Roskomnadzor (RKN) has not individually banned Hetzner servers for their content; instead, the government automatically blocks and throttles large parts of the Hetzner network via their TSCP systems (the hardware filters located at providers).

    The "Cheburnet" filters (DPI):
    In recent years, the Russian government has adjusted the filters so strictly that foreign cloud and hosting providers are distrusted by default. The DPI system recognizes the downloading of .xml.gz files from a German IP address and intentionally throttles the speed to ~1.6 KB/s until the connection times out.

    🚀 New Release: Version 1.4.9

    [⚡] Introduction
    We are excited to announce the release of version 1.4.9! This update introduces major stability enhancements, expanded VPN compatibility, and critical bug fixes to ensure seamless connectivity and performance.

    • 🔑 Version: 1.4.9
    • 📅 Release Date: 2026-06-30
    • 🧩 Compatibility: 100% LibreELEC 11, 12, 13 compatible (verified cross-platform support for x86, Raspberry Pi 4, Pi 5, and Generic Devices). Thanks to Reddirt and deepee.

    [⚙️] Changelog

    Core & Performance Optimizations

    • Fixed memory leaks by replacing global assignments with lazy-loaded references.
    • Converted dynamic config checks from daily intervals to precision hourly parameters.
    • Relocated state variables from /tmp/ storage to profile paths.
    • Optimized hardware timing for Raspberry Pi 4, Pi 5, and Generic Device architectures.

    VPN & Routing Enhancements

    • Added ProtonVPN via Custom Mode support.
    • Initial preparation for Mullvad VPN support (currently in development).
    • Fixed dual-default gateway collision using dual-bucket /1 split routing for PIA.
    • Added forced virtual interface data-ping to block ghost handshakes of PIA.
    • Dynamic MTU scaling maximizes packet throughput over standard links for PIA.

    Network & Security Hardening

    • Added automated tunnel integrity and routing verification checks.
    • Added network diagnostic test to verify tunnel encryption and stop IPv6 leaks.
    • Hardened ConnMan loop engine to isolate custom nameservers onto active interfaces.
    • Hardened connection teardown with route cache flushing and daemon restarts.

    Bug Fixes & Automation

    • Fixed cold boot and restart detection inside Service Launcher.
    • Fixed 55-minute handshake cache lockout bug for instant connection retries for PIA.
    • Added dynamic multi-tiered latency fallback engine for robust region updates for PIA.
    • Implemented persistent 10-min anti-abuse tracking with 15-min cooldown locks for PIA.
    • Added split-title error handling to display clear server and credential alerts.
    • Added manual trigger compatibility directly via HDMI-CEC keymaps.

    [📥] How to Update
    You can update directly via the official repository. https://github.com/BrodjagaRatnik…ository.doemela

    Quote

    Always remember to back up your current profile paths and settings before performing this update!

    [💬] Feedback & Support
    Please report any issues or share your feedback in the support section https://github.com/BrodjagaRatnik….manager/issues. Thank you for using our software!

    Are there any working OpenVPN client add ons for these nighties?

    On my Coreelec boxes I use the Zomboided OpenVPN add on.

    However after adding it's repository to the latest nightly, I get a 'could not connect to repository' error.

    When traveling I use my home VPN server to provide access to my media, so it would be nice if I could get an OpenVPN client running.

    Any tips or suggestions would be appreciated.

    It just runs on Kodi Omega 21.3 for me, and you don't need the repository at all; it's not maintained any more anyway. You can just download it here: https://github.com/Zomboided/serv…eases/tag/7.0.4

    📢 Important Developer Update: LibreELEC 12 vs. LibreELEC 13 (LE13)

    Hi everyone,

    The current release of the WireGuard VPN Manager Add-on is fully optimized for LibreELEC 12 and is working perfectly.

    Behind the scenes, I am already preparing the backend code for LibreELEC 13. LE13 brings a massive system change: LibreELEC is permanently replacing the old network engine (ConnMan) with the industry-standard NetworkManager.

    This change has a direct impact on our add-on. Here is a quick overview of what this means for us:

    🟢 The Advantages (Why LE13 is great news)

    • Rock-Solid Routing: No more random VPN disconnects when your router refreshes its DHCP lease. NetworkManager handles traffic routing intelligently in the background.
    • Stable Handshakes: The add-on will no longer crash due to system-level proxy or WPA Wi-Fi re-keying bugs.
    • Cleaner Backend Code: NetworkManager natively understands WireGuard. This allows me to remove messy "ip route" and terminal hacks from the Python code, making the add-on much faster and lighter.

    🔴 The Disadvantages & Impact

    • Potential Breaking Change: As LibreELEC shifts its network architecture toward NetworkManager in LE13, the current ConnMan-based routing functions of the add-on may break or become unstable on newer test builds until updated.
    • Backend Transition: I am proactively preparing a code migration to ensure the core functions can seamlessly talk to NetworkManager (nmcli) alongside the existing ConnMan (connmanctl) implementation.

    📅 What is the plan?
    Enjoy the current release on LE12 for now—it works great. I will take care of the heavy lifting for LE13 in the coming period so we can transition smoothly without losing any of our advanced features.

    Stay tuned for the first LE13 test builds!

    What you describe is not the case, I even flushed the main routing table and rebooted. Everything in the logs is fine.

    This must be something else.

    You can do:

    Shell session
    grep -Ei "error|warning" /storage/.kodi/temp/kodi.log | pastebinit
    Shell session
    journalctl -b 0 --no-pager | grep -iE "timeout|fail|network|waiting" | head -n 50 | pastebinit
    Shell session
    systemd-analyze; systemd-analyze blame | head -n 25 | pastebinit
    Shell session
    journalctl -p err..alert | pastebinit
    Shell session
    (journalctl -u vpn-watchdog.service; grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log) | pastebinit
    Shell session
    (echo "=== CONNMAN SERVICES ==="; connmanctl services; echo "=== CONNMAN STATE ==="; connmanctl state) | pastebinit
    Shell session
    journalctl -u connman | pastebinit

    Hi,

    Thank for the update; I tried what you said but it didn't fix the route.

    Any other suggestions to check ?

    If the split routing did not override the table, ConnMan is likely aggressively caching your old network state under a temporary session. To see exactly what is going on under the hood, please run these two commands in your terminal while the VPN is active and paste the output back here:

    Shell session
    route
    connmanctl services

    Without seeing your active routing table flags, it is impossible to see which interface is currently trapping your traffic. Paste those logs, and we will try to get it sorted.

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

    What happens: It pushes the filtered data straight to LibreELEC's default pastebin server and prints a clean link right inside your terminal window. Please share that link directly in this thread. Do not post full raw logs here!

    I looked into your routing table, and your analysis is 100% correct. The problem is a known ConnMan DNS routing conflict. Look at this specific line in your VPN routing table:

    Code
    10.2.0.1        192.168.101.254 255.255.255.255 UGH   0      0        0 wlan0

    Because you declared WireGuard.DNS = 10.2.0.1 inside your config file, ConnMan mistakenly generated a hardcoded Host route (UGH) that traps your DNS traffic. Instead of sending DNS requests inside the secure wg0 tunnel, it is forcing them out over your Wi-Fi card (wlan0) to your local router (192.168.101.254). Your local router has no idea what 10.2.0.1 is, so it drops the packets. This is why you can ping public IPs like 8.8.8.8 perfectly (via the VPN), but your DNS lookup times out, making your traceroute and reverse-DNS lookups extremely slow.

    Force the internal DNS into the tunnel you need to force the Linux kernel to override ConnMan's broken Wi-Fi route. You can do this by splitting the internet route into two smaller halves. Open your .config file and change the AllowedIPs line:

    1. Remove: WireGuard.AllowedIPs = 0.0.0.0/0
    2. Add: WireGuard.AllowedIPs = 0.0.0.0/1, 128.0.0.0/1

    Because a /1 netmask is more specific than a /0 default gateway, the kernel will ignore the Wi-Fi card and force your 10.2.0.1 DNS requests straight into the wg0 tunnel. Make sure to clean the network cache, restart ConnMan, and reconnect:

    Shell session
    rm -f /storage/.config/vpn-services/*
    ip route flush cache
    systemctl restart connman