Skip to content
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

Open
FuzzyExpress opened this issue Jan 26, 2024 · 16 comments
Open

WatchMate High background CPU when not connected. #57

FuzzyExpress opened this issue Jan 26, 2024 · 16 comments
Labels
bug Something isn't working

Comments

@FuzzyExpress
Copy link

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.
Screenshot_20240125_202701
image

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.

@azymohliad azymohliad added the bug Something isn't working label Jan 26, 2024
@azymohliad
Copy link
Owner

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

@FuzzyExpress
Copy link
Author

FuzzyExpress commented Jan 26, 2024

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 top with 0.3%, when unconnected it makes a consistent 1.3% use. This comment is collected while using Xorg, but I don't think the display server affects this app in this scenario due to it not using the GUI.

Edit: A Wild WatchMate caught in the wild among rouge bugged Nvidia programs:

Screenshot_20240129_230502

@FuzzyExpress
Copy link
Author

FuzzyExpress commented Jan 30, 2024

Screenshot_20240130_004639
Does WatchMate use any GPU acceleration perhaps (or a bug that would cause it to try to use the dGPU)? It shares the same symptoms as other dGPU apps that try to use my Nvidia card after sleeping (which breaks the GPU driver)
*Context for screenshoot, I tried to use the dGPU in blender, it broke, just like the nvidia-smi on the screen shot in the past edit

@azymohliad
Copy link
Owner

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 flatpak override --nodevice=dri io.gitlab.azymohliad.WatchMate. Though I would expect other GTK4 apps to behave similarly if that's the problem...

@FuzzyExpress
Copy link
Author

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.

@FuzzyExpress
Copy link
Author

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.

@azymohliad
Copy link
Owner

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.

@FuzzyExpress
Copy link
Author

I just woke my laptop back up from sleep after having dinner and WatchMate is once again in the broken state. However this time the Nvidia stuff isn't broken; nvidia-smi nvtop and Blender Cycles work as intended.
image
How bizarre.

@azymohliad
Copy link
Owner

azymohliad commented Mar 3, 2024

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:

flatpak install --user https://dl.flathub.org/build-repo/87429/io.gitlab.azymohliad.WatchMate.flatpakref

@FuzzyExpress
Copy link
Author

FuzzyExpress commented Mar 4, 2024

OHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

That makes a LOT of sense, I had a issue where my Bluetooth mouse wouldn't connect so I made an alias rsbt to restart the Bluetooth driver, I would run this many times a day, almost as much as I run the blender command.
The only thing I need now is to find the gosh darn charger, its been lost for prob 2 months now. If I ever find it or get ordered a new one I'll be sure to test it on my SteamDeck (the laptop died).

@azymohliad
Copy link
Owner

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.

@FuzzyExpress
Copy link
Author

FuzzyExpress commented Mar 5, 2024

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
that this Bluetooth loop problem had. There is a term for this, like narrow minded or something I don't remember exactly.

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...)
Now that we know the problem (we think) the watch will be useful again.

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.

@azymohliad
Copy link
Owner

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.

@FuzzyExpress
Copy link
Author

Oh, perfect timing! I just found my PineTime charger trying to dig my phone out of my bag after an exam.
I'll be sure to test it once it's available.

@FuzzyExpress
Copy link
Author

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 sudo systemctl restart bluetooth command, I've been using my mouse wired.

@azymohliad
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants