mirror of
https://github.com/JakeStanger/mpd-discord-rpc.git
synced 2026-07-11 09:15:30 +01:00
[GH-ISSUE #137] Extremely high CPU usage attempting to connect to Discord when it's not running #1629
Labels
No labels
bug
enhancement
help wanted
package
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/mpd-discord-rpc#1629
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @00dani on GitHub (Jun 13, 2024).
Original GitHub issue: https://github.com/JakeStanger/mpd-discord-rpc/issues/137
I'm on MacOS 14.5 and I've set up mpd-discord-rpc as a launchd service running at startup. This works just fine when DIscord is open. However, if Discord isn't running when mpd-discord-rpc is launched, then mpd-discord-rpc rapidly attempts to connect to it over and over, consuming significant CPU in the process.
I've done some quick digging into the
discord-presencecrate and found that the "No such file or directory" message is referring to the Unix socket$XDG_RUNTIME_DIR/discord-ipc-0, which indeed does not exist until Discord is launched.However, from what I can gather, the
discord-presencecrate is written to expect this situation, with the ability to wait between connection attempts as well as give up after a configurable number of attempts - by default it waits for five seconds between attempts. As far as I can tell, mpd-discord-rpc does not reconfigure this behaviour, but it's definitely not waiting five seconds between attempts.Is this a weird interaction between
discord-presenceusingstd::threadandmpd-discord-rpcusing non-blocking async through Tokio, maybe? The "wait before trying again" behaviour indiscord-presenceis implemented as a call tostd::thread::sleep, and I don't really know what happens if you try to call that from a Tokio application.@JakeStanger commented on GitHub (Jun 13, 2024):
Can you confirm which version of
mpd-discord-rpcyou're running? I've got a feeling this was an issue that was fixed, although I may be mis-remembering.@00dani commented on GitHub (Jun 13, 2024):
Just checked with
cargo install --list, I'm on mpd-discord-rpc v1.7.2, which is the latest release. 🤔@JakeStanger commented on GitHub (Jun 13, 2024):
Hm strange, I've not been able to replicate this on 1.7.2 or the latest git build. I'm wondering if it's perhaps related to the way threads are handled on MacOS vs Linux. Unfortunately I don't have a way of trying that myself.
That said, a potentially related update to the discord-presence crate has been put out which 1.7.2 doesn't include (unless Cargo feels like resolving it, which might be what's happening for me...). I've got the update on Git so I'll stick out a new release and see.
@JakeStanger commented on GitHub (Jun 13, 2024):
New release out - let me know if that helps
@00dani commented on GitHub (Jun 14, 2024):
Ran a quick
cargo install mpd-discord-rpc, I'm now on v1.7.3 - and it did! It's now waiting a sensible five seconds between attempts and barely produces a blip on my CPU, as it ought to be when there's no Discord to connect to:Thank you for checking this out!