SUMMARY KDE Connect has very high battery usage on phone STEPS TO REPRODUCE 1. Install KDE Connect on phone, set battery not optimized 2. Pair with pc. OBSERVED RESULT About 50% battery usage when computer is running and connected. Average 33% usage after two days, computer was off about 40-50% of the time. EXPECTED RESULT SOFTWARE/OS VERSIONS Phone: OS: LineageOS 17 KDE connect version: 1.17.0 PC: OS: Debian unstable KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION No activity between devices other than notifications from phone to pc.
Created attachment 141809 [details] High battery usage Its the most energy expensive app on my phone while doing nothing
I suspect that this app prevents the device from going into "Deep Sleep" mode as I am getting notifications from other apps that normally do not run when the device is not in use. Also I imagine that some of the features when enabled, like 'report battery status' and 'find my phone', have to prevent the device from sleeping thus draining the battery faster. I am using the F-Droid version if this makes any difference.
Created attachment 145090 [details] Battery usage statistics, KDE uses more then Android system
+1, please add option to disable and manual enable only when needed. Otherwise it's unusable for me. Moreover, it's better for security not to run services you don't need at the moment.
I am also affected by the high battery usage since a couple of days. Just a guess, but it seems to be correlated with me binge-watching a series using Haruna. Is it possible that media plugin / MPRIS is spamming communication with the phone? Version 1.19.1 from F-Droid Operating System: Arch Linux KDE Plasma Version: 5.26.1 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.2-zen1-1-zen (64-bit) Graphics Platform: Wayland
KDE Connect daemon on Linux uses 10 second keep-alive interval on TCP socket. In other words, it pings the phone every 10 seconds, preventing the CPU and Wi-Fi module from deep sleep. It's unfortunate that I could not convince the developers to accept my patch. See https://bugs.kde.org/show_bug.cgi?id=441830 https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/447
I am also affected since last Android app update to version 1.20.1.
I have downgraded Android app to 1.19.1 and it works much better.
I have figure out the problem: vlc sends a lot of Seeked dbus signals (about four per second) when I watch a tv channel stream in my notebook. kdeconnect-kde's mutimedia control receiver plugin in my Plasma desktop relays all those signals to the android app through the tcp link (four tcp packets per seconds!!!). One workaround is disabling the multimedia control receiver plugin, but then I cannot play/pause vlc anymore. I have created a patch to kdeconnect-kde to add a 5 seconds delay before sending any Seeked data and it improves my cellphone battery and I still can play/pause vlc. Of couse, that is not a solution, it is just a workaround. I think kdeconnect-kde should not send data that is useless to the android app. I mean, my cellphone is locked, there is no need to update the progress bar in android app's multimedia control plugin. There is still another reason: the tv channel stream is infinite stream, there is no way to calculate it's ending, so there is no way to calculate the progress bar's maximum value. By what I could guess, the android app uses 100 minutes as the default maximum value, but all vlc's Seeked values are bigger than that, so the progress is always at the end of the progress bar. In my opinion, the android app should send to the kdeconnect-kde if the cellphone is locked and if the app is visible. If the app is not visible, then the kdeconnect-kde should avoid sending any data that are only used to update the widgets in the android app. The if cellphone is locked, then the plasma applet should also increase the interval to send any data to the cellphone, so the cellphone can have a chance to save battery.
Really this is probably a bug in VLC. Per the specification, compliant MPRIS players should *never* emit `PropertiesChanged` for the `Position` property and should only emit `Seeked` when the position changes in a way that is inconsistent with the current playback rate (i.e. when the user actually requests seeking). There are a couple ways you can try to deal with uncompliant MPRIS players, but none of them are reliably and might even result in breaking compliant players.
My vlc's problem is similar to this one: https://code.videolan.org/videolan/vlc/-/issues/26564