Live data from Hacker News

KDE Connect: Enabling communication between all your devices

community.kde.org

131–140 of 208 posts

Re: KDE Connect: Enabling communication between all your devices

#131
post #12

when it works it's amazing. but very often both my phone and laptop are connected to the same WiFi, yet kde connect can't see them. I can't figure out how to diagnose and solve that when it happens

It has really got unreliable in my experience.

Often desktop client just cannot connect to mobile. At first I noticed that this happens when desktop client starts to output in logs these (reported [1]):

  kdeconnect.core: Too many remembered identities, ignoring "" received via UDP
Restarting desktop client helped, so I wrote watcher that monitors logs for such lines and restarts kdeconnect. But it turned out to be insufficient. Now I have this script running in background to restart kdeconnectd whenever connection is missing, and finally can use KDE Connect reliably:

  #!/bin/dash -x
  
  
  while sleep 1m; do
      nmcli connection show --active | grep wifi || continue
  
      kdeconnect-cli -l | grep reachable && continue
  
  
  #   notify-send 'No reachable devices via kdeconnect. Restarting'
      systemctl --no-pager --user status app-org.kde.kdeconnect.daemon@autostart.service
      systemctl --no-pager --user stop app-org.kde.kdeconnect.daemon@autostart.service
      killall kdeconnectd
      systemctl --no-pager --user start app-org.kde.kdeconnect.daemon@autostart.service
  
  done

[1] https://bugs.kde.org/show_bug.cgi?id=506563

Re: KDE Connect: Enabling communication between all your devices

#132
post #91

How well does this work for sending a lot of files without re-sending the same file? I have a desktop + laptop + phone. When I want to sync a directory with a lot of files I wrote a little shell script that uses rsync to do it. This does require running SSH on my laptop but I can invoke the shell script from my desktop. Likewise with my phone I want to backup my camera photos, using rsync is nice here to avoid sendin…

For this purpose, I would not suggest KDE Connect. What you're looking for is something more like SyncThing: https://syncthing.net

I thought about SyncThing in the past but was reluctant because I don't have a centralized server and I don't always want 1 device to be the definitive source of truth.

For example:

    - On desktop, wrote a blog post
    - On desktop, pushed my blog post folder to my laptop
    - On laptop, publish the blog post 3 days later
    - On laptop, fix a typo and publish the post
    - On desktop, pull in the changes from the laptop
The same type of situations happen with KeePassXC's database file. Sometimes I make an update on my phone or laptop and want it sent to my desktop, other times I make the update on my desktop and want it sent to the other 2 devices.

With SyncThing, would this overwrite files on the wrong device as soon as I "sync"?

Re: KDE Connect: Enabling communication between all your devices

#133
post #83

KDE Connect has been my answer to Apple's Airdrop for the last couple of years. It's an excellent program; I even use it on my Mac for file transferring with my Steam Deck

Another good one for this is Localsend.

https://localsend.org/

Re: KDE Connect: Enabling communication between all your devices

#134

Earlier quoted context omitted.

I agree with your assessment of KDE lacking "taste". Imo, it looks like a system designed by engineers, not designers. GNOME has the opposite problem imo. I feel like it has "taste", but it feels like a system fully designed by designers, with no engineers giving practical pushback. It's the same issue macOS has, but amplified: Designers have some grand idea about their vision being the one true way of using the syst…

> I agree with your assessment of KDE lacking "taste". Imo, it looks like a system designed by engineers, not designers. TBF, I was linked their more up to date screenshots in a sibling thread and it does look more consistent but it still seems off. > I currently use KDE, but am not happy with it for the reasons you described. I used to use GNOME, but wasn't happy with it for the reasons above. I don't like any of th…

Do you think GNOME has similar UI issues? In my view, it's "pretty", but just doesn't let me configure it the way I want it to without hacking around way too much.

Re: KDE Connect: Enabling communication between all your devices

#136

The feature set commenters here want is insane: * fast as possible * LAN, but also WAN when necessary * in fact how about multi-protocol, and use the fastest protocol that's available on both devices, it's 2025 people! * work for sending a gargantuan amount of files with possible interruptions (essentially, be rsync) * be battery efficient, it's 2025 people! * don't rely on a centralized cloud server, just connect th…

>* be battery efficient, it's 2025 people! It took a long time for me to prove that what KDE does negatively impact the battery life. https://bugs.kde.org/show_bug.cgi?id=441830 The other user even wrote a LD_PRELOAD hijacking library to not recompile the application every time https://github.com/max0x7ba/kdeconnect-powersave-keepalive

A 5 second keepalive seems unnecessary, but does that actually impact battery life? How long does the device take to move in and out of powersave states? I'd think you'd be looking at maybe 20-40 microseconds of CPU time to handle the packet, so 0.0008% of the time awake due to this. Are other parts of the device just super slow at moving in and out of powersave states?

Re: KDE Connect: Enabling communication between all your devices

#137
post #77

Earlier quoted context omitted.

Android doesn't really have such a thing as quitting an app. You're meant to just stop doing stuff when off screen, and let your app be evicted in LRU order (or whatever order is actually used). If your app does background stuff you should have a settings toggle to do the background stuff or not, and when it's on and the phone is on, you do the background stuff.

This is not true: https://stackoverflow.com/a/40231289

This closes an activity - the user interface of an app - not an app. In Windows terms, this is DestroyWindow, not ExitProcess.

You can also exit an Android process, of course. It's probably what you're looking for, but it's weirdly inconsistent with the overall user experience and you should try to make something consistent instead. Even closing a top-level activity is weird.

Re: KDE Connect: Enabling communication between all your devices

#138

Earlier quoted context omitted.

It should work on any network where mDNS works and where TCP connections can be established. There's not much going on that's more complicated than that when it comes to device discovery. Many VPN configurations break mDNS and other broadcasts (i.e. Chromecast, file shares, that kind of thing), though. A lot of "how to get started with WireGuard/OpenVPN/etc." guides stop the moment HTTP(S) connections work, but there…

Oh, so if I setup mDNS on my workstation KDE Connect will be more reliable? Kind of annoying since I DNS already works to resolve names.

Your desktop probably already has mDNS set up, most user-friendly distros do it out of the box.

But it doesn't really matter, because KDE Connect implements its own sort-of mDNS system by itself, in the form of JSON broadcast across the local network on a standard port offering hostnames, services, and other metadata. Actual, real mDNS would require integration into the host's networking setup and that's too much to ask for clients like Android or iOS and you'd need to implement it manually in many other cases, so they kind of made their own mDNS. It also means you don't need root access to run KDE Connect on your device, which makes it viable on platforms like the Steam Deck.

To get KDE Connect working reliably, you need to make multicast traffic work reliably. Every network has its own restrictions when it comes to multicast so it's hard to know what specific tweaks your workstation needs. Having KDE Connect open on your phone, you should see packets coming in on your desktop on 255.255.255.255 on 1716/udp.

Re: KDE Connect: Enabling communication between all your devices

#139
post #82

Earlier quoted context omitted.

I liked Slackware a lot way back when. No deeper reason. Currently leaning towards Debian Testing, but that might depend on my testing of Slackware now. I use Arch daily in WSL, but I've have had enough breakages that I don't want it as my primary OS.

I use Debian 13 (stable). It is very solid. I was using Debian Trixie when it was testing and there was breakage twice. I would make the /boot partition twice the size the installer suggests though as on my laptop I can't upgrade the kernel because the /boot runs out of space. The laptop is used to view old manuals in PDFs while working on my car so I don't really care. TBH any of the major Linux distros that have be…

Debian is a very solid, stable, but slow-moving distribution.

Re: KDE Connect: Enabling communication between all your devices

#140

The feature set commenters here want is insane: * fast as possible * LAN, but also WAN when necessary * in fact how about multi-protocol, and use the fastest protocol that's available on both devices, it's 2025 people! * work for sending a gargantuan amount of files with possible interruptions (essentially, be rsync) * be battery efficient, it's 2025 people! * don't rely on a centralized cloud server, just connect th…

>* be battery efficient, it's 2025 people! It took a long time for me to prove that what KDE does negatively impact the battery life. https://bugs.kde.org/show_bug.cgi?id=441830 The other user even wrote a LD_PRELOAD hijacking library to not recompile the application every time https://github.com/max0x7ba/kdeconnect-powersave-keepalive

Fixed in "Remove custom keepalive intervals" merged 12 Aug 2024

https://invent.kde.org/network/kdeconnect-kde/-/merge_reques...

Post reply on HN