On networks with many KDE users, extension freezes desktop

[ghost]

I've tried this extension at home and it works super there. (Thanks a lot for your great work!)

However, at work, as soon as I open the extension's settings window, my desktop essentially freezes for minutes (or at least until I kill it). A contributing factor here might just be that we have a larger number of KDE devices in the network (think 100+), most/all of them with at least the server bits of KDEConnect installed.

The KDEConnect Android app only seems to show the first ten or so devices it sees in the UI. I guess all other devices need to be contacted by entering their IP addresses.

(This is using GNOME Shell 3.26 and GSConnect 11.)

[andyholmes]

Hmm, well there's a couple things to say about this. First, I've never tested with that many devices :)

It's well known that Gnome Shell extensions monkey-patch the running JavaScript, so essentially "run in the same thread". GSConnect has two parts: a server in it's own process (using threads where made available by the GTask API), and the actual Shell extension which draws the widgets and so on. Incidentally, the preferences window runs in it's own process as well.

Given that your desktop is locking up, it's fair to say that it's probably the Shell extension that's the worst culprit, otherwise you would probably experience heavy CPU usage from the server in the worst case, but not outright freezing. This probably happens when you open the settings window because the first thing it does is send out a single broadcast packet, which those 100+ devices respond to.

There's not much I can do about the Shell extension, since it's about as asynchronous as it can be and really only responds to DBus signals/property changes from the server. I think the best way to deal with this is to add a "whitelist" for device IPs to the server early in the connection process, possibly one that engages automatically if a number of concurrent devices make contact.

I'm currently pretty deep into the rewrite I've been working on to backport anything, but if I added this feature into that would you be willing to test a build?

[ghost]

Thanks for the quick response and sure, I would love to test!

[andyholmes]

Sorry, I got caught up in a lot of things, but I wanted to get you a test build since freezing your desktop is pretty bad. I spoke with Albert, one of the lead developers of KDE Connect, and he acknowledged the problem and suggested a "discovery" mode like Bluetooth has. In this case, unpaired/unknown devices would only try to connect if both devices are in discovery mode. Since this isn't implemented in KDE Connect yet either (Android or desktop), I've set discovery mode to be off by default and there is a "Connect to..." option in the main settings hamburger menu (known devices can always connect though):

So here's build from my local repository (not pushed) that's rough in places, but should work fine. Fair warning, this should be compatible with your current settings, but may not be forward-compatible and if you later go back to the main branch you should definitely clear your settings first (I think the FAQ has instructions). Give it a shot if you feel up to it.

EDIT:

Sorry, there was a silly mistake in that build, this one should be good:

gsconnect@andyholmes.github.io.zip

[ghost]

Thank you for the preview version (and I really don't mean to put pressure on you).

Anyway, I have quickly tried it:

• The ~desktop freeze when opening the extension window is gone but there is noticeable lag (maybe 1 or 2 seconds) when e.g. logging in and GNOME Shell is starting. (Which seems fine to me.)

• I think I am too stupid for the IP dialog -- I didn't manage to connect. Neither from the Android app nor from GSConnect.

  • On Android, I tapped "Add device by IP address" (rough translation), added my computer's host name to the list, returned to the main screen and tapped "Refresh" -- nothing happened, my host name still wasn't in the list.
  • On Linux, I opened the "Connect to" window of GSConnect, typed my phone's IP address -- nothing happened. (Note that I tried pinging the respective other end in both cases and it worked fine, so it's probably not a typo.)

I also tried enabling debug mode but that turned out to be a recipe for getting the desktop irresponsive again.

[andyholmes]

Yeah, I noticed that (different) lag too. It started the last few days with some change I made, so I'll track it down and revert whatever caused it (eventually :P).

Hmm, I assume that you cleared your dconf/GSettings for GSConnect and restarted Gnome Shell if it worked at all? The IP dialog is pretty straight-forward and there's a simple regex check on the value, so it's probably not your fault. Enabling debug mode or opening the Debugger window shouldn't cause a freeze, so there must be something funky going on.

Are you using Gnome Shell 3.26+? I should have mentioned that's a requirement for the rewrite, since it uses a bunch of newer JavaScript features. I test it on 3.28, but it should definitely work on 3.26.

[ghost]

To answer the questions I can:

• Yes, I am using GNOME Shell 3.26.2.
• To install, I unzipped into ~/.local/share/gnome-shell/extensions/$uuid and ran "gnome-shell-extension-tool -e $uuid"; I think that did not properly work initially, so I logged out and back in.
• I did not clear dconf. How do I properly do that, do I just need to delete the file somewhere?

[andyholmes]

Try this:

1. Disable the extension, then rm -rf ~/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io
2. Run dconf reset -f /org/gnome/shell/extensions/gsconnect/
3. Install this zip and then restart Gnome Shell and try again.

This shouldn't all be necessary, but it's worth trying to be sure the problem is with the extension itself and not leftover settings or files. You can ignore the "Device" dropdown in the "Connect to..." dialog, it's just something for bluetooth I'm working on.

[ghost]

Unfortunately, with the new build I can't get the "Connect to" window to open. (The regular settings window works, just selecting the menu item "Connect to" does nothing.)

[andyholmes]

Sorry, I left this for a little bit, I'm glad to get some testing in this area. I was working a bit on #158 and didrocks reported some worrying CPU spikes and errors, so I wanted to get those sorted before I offered you another build. Give this one a shot and let me know if it works better:

gsconnect@andyholmes.github.io.zip

Shoot, sorry. This one:

gsconnect@andyholmes.github.io.zip

[ghost]

Sorry for the really late feedback. :( Unfortunately, the new version does not really help me.

• It takes tens of seconds before my desktop appears after login.
• It takes ~5 seconds before the GSConnect settings window appears.
• After clicking Connect in the IP address window, nothing happens -- no error/success message, no change in listed devices, etc.
• Renaming my computer using the little pen icon at the top of the settings window from the default "GSConnect" to something else seems to freeze the desktop (either for good or I was too impatient).

[andyholmes]

No problem, we both see to be intermittently busy :)

I've made a number of other changes, but I'm suspecting their might be some leftover service file or setting from one of the Zips that is causing GSConnect to misbehave, since I don't experience these hangs at all.

I'll try and get a Zip in shape for you to test soon, and give you a little script or list of files to wipe that I think might cause a problem so it can be ruled out. Thanks for continuing to test, this is a hard situation for me to emulate on my home network.

[ghost]

@andyholmes fwiw, I tried writing my own clean-install/uninstall script, https://github.com/sknorr/wastebin/blob/master/gsxinstall

[andyholmes]

That's a great idea, thanks for sharing. I'm really trying to get all the big changes staged locally so that I can push and merge the new branch in the next few days and get a move on with it. Once that's done I plan on a little more cleanup and then a release candidate, and having this script would be super useful for testers.

I have a Zip here you can try on you large network before then if you like. I'm not so confident about this one, but it uses a crude approach of automatically turning off Discovery when a 3rd device is detected. Feel free to wait a few days or give it a shot if you like:

EDIT sorry, don't use that. There was a really bad bug in the networking that caused an infinite loop.

[andyholmes]

I've just managed (finally) to merge the rewrite into master. There's an alpha on the releases page that I think should be pretty stable now. Discovery turns on at the 3rd device, and there shouldn't be any crazy CPU usage this time around :)

[andyholmes]

I'm going to label this "fix committed" since I'm pretty sure the auto-off discovery feature in master works. Let me know if it's still not good enough and I'll re-open.