New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WatchMate High background CPU when not connected. #57
Comments
Thanks for the report. I noticed it too after leaving it in the background for a long time. No ideas yet on what's causing it. Will try to take a closer look in Feb |
I have looked at is several times today, no peaking today, connected or not. I never seems to reconnect to my watch after sleeping, but that's not really a problem, though it does have higher CPU use while not connected, when it was connected it would occasionally show up on Edit: A Wild WatchMate caught in the wild among rouge bugged Nvidia programs: |
Hm.. That's an interesting theory to check. GTK4 can use it. Are you using Flatpak or a native distro package? For flatpak you can try to disable GPU acceleration permission with Flatseal or |
I am using Flatpak, I'll try disabling GPU acceleration and see if it has a effect on it. I haven't seen the other GTK app I use, EasyEffects, have a problem like this though. EasyEffects isn't installed via Flatpak, I wonder if Flatpak could have some reason to do with this. I'll be sure to let you know if the override fixes it or not. |
I believe I have confirmed that that is in fact what is happening. I applied the suggested flatpak override, but didn't reboot the app or my computer, and after sleeping it did the same thing again. After a rebooting and then sleeping it does not have this issue anymore it seems. Annoying that sleeping breaks everything wanting to use the dGPU, but glad to have this app fixed. |
Nice, thanks a lot for figuring that out! I'll try to confirm this on my end too. One potentially relevant difference between Watchmate and some other GTK4 apps is how the background mode is implemented: Watchmate simply hides the window, and some other apps I examined properly de-initialize the UI. The bad news is that Relm4 (the layer on top of GTK4 that Watchmate is built with) doesn't allow to implement background mode properly. So if that's the root cause, a proper fix might require a full rewrite in plain GTK4. I was considering it before, as it would bring some other benefits, and it shouldn't bee too hard, but I'm really not sure when I'll find the time and motivation. |
Hi! I am now reasonably sure I found the root cause and fixed it in #62. After bluetooth adapter restart (e.g. after system suspend) and with the right timings, the device discovery could stuck in an infinite loop without yielding the thread. I want to include some more fixes and additions into the next release and test it more, so I'm not sure when I'm gonna release it. But if you'd like to try this earlier, you can install this test build from Flathub CI:
|
OHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHThat makes a LOT of sense, I had a issue where my Bluetooth mouse wouldn't connect so I made an alias |
Don't stress about testing it if it takes an extra effort. Of course it would be good to know if it helped, but there's no rush with that. This fix is useful anyway, and will be included in the next release. And if it turns out that it doesn't actually solve this issue, we'll just keep looking for the cause. |
No, you haven't caused me any stress. :) That was just my unnecessarily dramatic expression of my surprise that over the entire time we spent trying to figure it out, that I never once stopped to considered that it maybe wasn't a GUI problem but a Bluetooth problem. That makes sense given that other app's GPU Hanging problem has the same 100% CPU use Either way you also reminded me I had this watch, and that I should probably use it instead of it just being a whist weight? (I don't think having a paper weight for your wrist is exactly normal...) This along side #59 Auto Reconnect putting this on multiple computers might be practical. I'll try this as well once I get my watch up and running. Thanks for making this nice easy to use app. |
FYI, I've released this fix as v0.5.2 (should appear on flathub in a few hours). It turns out all the other improvements I wanted to include in the next release will take more time than I expected. |
Oh, perfect timing! I just found my PineTime charger trying to dig my phone out of my bag after an exam. |
Update: I have not yet seen the CPU spike issue happen at all with the new package! I've put my KDE Neon Unstable Mac and Steam Deck to sleep and resumed several times, no CPU spikes, well not from WatchMate anyways, which is great. (steam did it once). the watch still often does not reconnect after walking out of range or sleeping, but I can open WatchMate and reconnect it. Now I will note that I have not used the actual |
Ok, thanks, it's good to know that auto-reconnection still has issues (re #59). I recently learnt that there might be a more reliable and efficient way to auto-reconnect if the device is bonded. So the plan is to implement secure connection first (#56), and then try to improve auto-reconnection. I'm half-way through secure connection implementation, but a bit busy this weekend, so will probably get back to it not earlier than the next weekend. |
My PineTime is not connected to my laptop, and WatchMate is using 100% of a core. This is after having had restarted the BlueTooth driver several times.
I am running Kubuntu 23.10 | KDE Plasma 5.27.8 | Wayland | 6.6.8-x64v3-xanmod1 Kernel.
Let me know how to provide more information and I'll be sure to add it.
The text was updated successfully, but these errors were encountered: