Closed sentakuhm closed 4 months ago
Hi @sentakuhm 👋
Thank you for raising this. I have not seen it get anywhere near to that % before!
I will investigate this as part of the next release. To help me, could you please let me know the following:
clipse --listen-shell
or was it only this process? Thanks!
OS: Arch linux. Terminal: Kitty. WM: Hyprland. Clipboard: wl-clipboard.
Settings on hypr:
exec-once = wl-clipboard-history -t
exec-once = clipse -listen
bind = SUPER, V, exec, kitty --class floating -e zsh -c 'clipse $PPID'
as i said its not always happen, but i think it happen on copying media files images/videos. and no, no other other process spike at the same time only clipse.
I record what happened when i take screenshot, this may help you inspecting the issue:
https://github.com/savedra1/clipse/assets/25133437/0a319103-4a63-4e79-bb13-efc67760fb51
@sentakuhm thank you!
Looks like this is mainly gonna be down to the content type being copied (media data specifically).
I think I have a fix so gonna work on that as part of the next release. Will keep you updated 😄
@sentakuhm I've published a new release that should have sorted this out a bit, haven't got the new Nix/Aur package sorted yet but lmk if you get this working in the meantime if it's helped at all :)
edit - what are you using to record your desktop out of interest?
@savedra1 i'll check it out, and i use wf-recorder for desktop record.
Edit: build from source and seems worse than before, CPU usage about 67-85%.
Thank you @sentakuhm 🙏 been looking for a good one. let me know how it goes
@sentakuhm have just seen your edit!
Am very surprised to hear this as the change I made included significantly reducing the rate at which the app would check your clipboard contents when media data is held. The only thing I can think of that would increase the cpu usage is the updates to the UI used for this release but that should not apply here and would be super minimal.
As you built this from source, are you 100% sure the previous version is not the one that's running the listener still? Eg if you still have the previous installed, running clipse -listen
maybe be using that still. I'd recommend using ./<new clipe binary> --listen shell
.
The new AUR package should also be good to go now btw, maybe installing from there would help.
If it is the new version I'll need to have a deeper think about this as it's possibly caused by the way it interacts with your hyprland/shell envs.
Lmk!
Thanks :pray:
Yes, first i completely removed the old version and build from the source, second i remove built one then installed from AUR, checking with clipse -v
the output is: clipse v0.0.7
also i reboot my pc, but both gave same issue, now the issue is happen even when copy a text too.
to be sure this is my settings:
exec-once = wl-clipboard-history -t
exec-once = clipse -listen # run listener on startup
bind = SUPER, V, exec,[float;size 450 590] kitty --class floating -e zsh -c 'clipse' # [float;size 450 590] is just custom window size.
Edit: do you use wl-clipboard
?
Thanks for confirming @sentakuhm. Yeah I use wl-clipboard
.
I see you're also running the wl-clipboard-history
script on startup, this shouldn't directly affect the behaviour of clipse but as they would both be interacting with the system clipboard simultaneously I wonder if this is causing any complications.
I would suggest stopping the wl-clipboard-history
script to see if that makes any difference. Alternatively you could not run the clipse-listen
and update the wrapper around wl-clipboard
so that it updates the history file instead, though that would require a lot more engineering effort. Will try and replicate this myself also.
Planning to cross-compile some c
for a more event-based clipboard listener, was reluctant to use an extra dependency for this wl-clipboard
but may look into making that a temporary option
https://github.com/savedra1/clipse/assets/99875823/7d87ecc4-e64b-4ad8-8567-c4702f48884b
This is my htop when copying a large image file on the new release (2% CPU). What machine specs are you running? wondering if that could be making a difference also
stopping the wl-clipboard-history
script no helping.
is there any option to debug?
I see :thinking: debugging in clipse is still limited to error messages. When clipse -listen
is ran it executes the command nohup clipse --listen-shell >/dev/null 2>&1 &
which discards all logs, but you could recreate this, getting it to point to a log file instead with nohup clipse --listen-shell >> /path/to/logfile.log 2>&1 &
and see if that shows you anything helpful.
You could also edit the source code to add print statements if you already have an idea of what you'd be looking for here. In that case you could simply run clipse --listen-shell
and see what gets printed to the terminal while the process runs.
I haven't been able to recreate this also so still wondering if it could be hardware related. Will see what debugging logs I can find though and let you know if I spot a way to find some clues.
on log file there is no thing except nohup: ignoring input
.
Thank you for checking @sentakuhm. Looks like I would need to implement some better, system-level debugging here for that to show any info. I'm sorry we haven't got very far with this, I'm not sure of the cause still but you could try the following:
strace
/perf
to inspect the PID of the running listener process. EG strace -p <PID>
ps aux | grep clipse
to ensure only a single clipse process is running (something might be going wrong when terminating an existing listener) clipse -kill
can then be used to kill all sessionsclipse --listen-shell
directly in a terminal without the nohup
process to see if this helps (maybe nohup is causing some system issue) These are the only things that come to mind for ways in which clipse is interacting with your system. If none produce any positive results will need to think about other ways to analyse what's going on under the hood when the binary runs on your system.
Your perseverance is much appriciated, let me know how it goes! :smile:
OMG!! what a relief, clipse -clear
solved my issue, even after rebooting and try again cpu was only 2%. thank you!!!.
Amazing! Must've been some unexpected binary data pattern from a certain file.
Will keep this in mind and add to the FAQs.
Thanks again for sticking with it and for using clipse 🫡
I also get this on NixOS unstable + Hyprland... clipse eat more cpu than firefox.
Hi @ArtemChandragupta,
Have you tried the above fix? should be due to the bin data from a certain image file causing a parse issues.
EDIT: 0.5% CPU actually sounds fairly normal, surprised at how low everything else is tbh :laughing:
Is the fix is just to do clipse --clear to remove all clipboard history? Can I just remove image files by 'x' keybind?
This is not truly 0,5%, btop is weird. It actually more like 4%, because now it uses 7% of cpu while before it used something like 3% in same situation. And it is important, because I notified that by temperature increase.
This is without clipse, same tabs are open in firefox. Completely different cpu usage graph
Gotcha @ArtemChandragupta
You shouldn't need to clear everything, likely just a particular image file causing the increased usage so you can try deleting individual files using x
, I guess that just takes longer.
Planning to implement more specific clear commands in the future, to specifically clear all images/non-pinned items etc. This is all I can suggest for now though. It's on my radar as something to look into more, let me know if you still get higher than expected usage after removing your images though.
Issue is still here after clearing the buffer...
Congratulations! Now (maybe with 1.0.7 patches, while I am on 1.0.9) CPU usage is good on my machine. Now I can say that clipse is my favorite clipboard history project.
thank you @ArtemChandragupta!
it not always, just sometimes cpu is high