[GH-ISSUE #204] Keeps spawning threads when Discord isn't open

JakeStanger commented

2026-05-22 22:03:43 +01:00

Owner

Originally created by @miku4k on GitHub (Apr 28, 2025).
Original GitHub issue: https://github.com/JakeStanger/mpd-discord-rpc/issues/204

It spawns a new thread about once every 5 seconds. I'm at about an hour of uptime, and it's at about 900 threads now. I don't have Discord open. The memory consumption grows accordingly, currently at about 30MB. It's especially noticeable with a longer uptime, where it might be at over a GB of memory used. CPU usage doesn't seem to go up. IO read doesn't seem to go up either, tho it's at 7.8MB currently, which feels like a lot.

This is not a major problem for me personally, as I don't have Discord running most of the time, meaning I can just disable it without problem.

Checking journalctl, there's a lot of

Context { event: Error(ErrorEvent { code: None, message: Some("Io Error") }) }
JDFJDFJDF
thread '<unnamed>' panicked at src/main.rs:159:26:
channel to be open: "Full(..)"

and some

 INFO mpd_discord_rpc: starting drpc client
ERROR mpd_discord_rpc: disconnected

(timestamps stripped)

Originally created by @miku4k on GitHub (Apr 28, 2025). Original GitHub issue: https://github.com/JakeStanger/mpd-discord-rpc/issues/204 It spawns a new thread about once every 5 seconds. I'm at about an hour of uptime, and it's at about 900 threads now. I don't have Discord open. The memory consumption grows accordingly, currently at about 30MB. It's especially noticeable with a longer uptime, where it might be at over a GB of memory used. CPU usage doesn't seem to go up. IO read doesn't seem to go up either, tho it's at 7.8MB currently, which feels like a lot. This is not a major problem for me personally, as I don't have Discord running most of the time, meaning I can just disable it without problem. Checking journalctl, there's a lot of ``` Context { event: Error(ErrorEvent { code: None, message: Some("Io Error") }) } JDFJDFJDF thread '<unnamed>' panicked at src/main.rs:159:26: channel to be open: "Full(..)" ``` and some ``` INFO mpd_discord_rpc: starting drpc client ERROR mpd_discord_rpc: disconnected ``` (timestamps stripped)

JakeStanger

2026-05-22 22:03:43 +01:00

closed this issue
added the
bug
label

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jun 22, 2025):

I believe this has been resolved and am not able to replicate on the latest git release, so closing this. If it's still an issue let me know and I can re-open.

@JakeStanger commented on GitHub (Jun 22, 2025): I believe this has been resolved and am not able to replicate on the latest git release, so closing this. If it's still an issue let me know and I can re-open.

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@miku4k commented on GitHub (Jun 22, 2025):

hi i just checked on the latest git and this still happens.

i looked at the code and i believe the problem is at src/main.rs:102. the start method on discord_presence::Client spawns a new thread every time, im guessing its supposed to only be called once.

@miku4k commented on GitHub (Jun 22, 2025): hi i just checked on the latest git and this still happens. i looked at the code and i believe the problem is at [src/main.rs:102](https://github.com/JakeStanger/mpd-discord-rpc/blob/master/src/main.rs#L99-L103). the `start` method on `discord_presence::Client` spawns a new thread every time, im guessing its supposed to only be called once.

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jun 22, 2025):

I'm not convinced that's the problem, unless I'm missing something.

That start method creates a thread which starts up the internal connection manager in discord_presence:

github.com/jewlexx/discord-presence@e17c4c66fc/src/client.rs (L136)

That in turn calls send_and_receive_loop:

github.com/jewlexx/discord-presence@e17c4c66fc/src/connection/manager.rs (L63)

That sends the error event we care about here, and will break for any "connection refused" type IO Errors.

github.com/jewlexx/discord-presence@e17c4c66fc/src/connection/manager.rs (L164-L174)

Once that breaks, that's the end of the thread.

How are you replicating/observing this? I've tried leaving the program running with Discord closed and a reduced idle time, and seen no increase in memory.

@JakeStanger commented on GitHub (Jun 22, 2025): I'm not convinced that's the problem, unless I'm missing something. That `start` method creates a thread which starts up the internal connection manager in `discord_presence`: https://github.com/jewlexx/discord-presence/blob/e17c4c66fc6d6c314c70578235775514a33c2552/src/client.rs#L136 That in turn calls `send_and_receive_loop`: https://github.com/jewlexx/discord-presence/blob/e17c4c66fc6d6c314c70578235775514a33c2552/src/connection/manager.rs#L63 That sends the error event we care about here, and will break for any "connection refused" type IO Errors. https://github.com/jewlexx/discord-presence/blob/e17c4c66fc6d6c314c70578235775514a33c2552/src/connection/manager.rs#L164-L174 Once that breaks, that's the end of the thread. How are you replicating/observing this? I've tried leaving the program running with Discord closed and a reduced idle time, and seen no increase in memory.

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@miku4k commented on GitHub (Jun 22, 2025):

i simply watched the thread count in btop go up.

i ran a very simple test and the start method does in fact start a new thread every time.

Test code

fn main() {
    let mut discord_client = discord_presence::Client::new(1337);
    loop {
        std::thread::sleep(std::time::Duration::from_secs(1));
        discord_client.start();
    }
}

i also looked at the code you linked and the thread stays in the loop, because should_break() only returns true for IoError(ConnectionRefused) and connection_attempts is None

btw discord closed means fully closed, not just closed to the tray or anything

@miku4k commented on GitHub (Jun 22, 2025): i simply watched the thread count in btop go up. i ran a very simple test and the `start` method does in fact start a new thread every time. <details><summary>Test code</summary> <p> ```rust fn main() { let mut discord_client = discord_presence::Client::new(1337); loop { std::thread::sleep(std::time::Duration::from_secs(1)); discord_client.start(); } } ``` </p> </details> i also looked at the code you linked and the thread stays in the loop, because `should_break()` only returns true for `IoError(ConnectionRefused)` and `connection_attempts` is `None` btw discord closed means fully closed, not just closed to the tray or anything

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@Jkizzyfoss commented on GitHub (Jul 19, 2025):

I observed this issue too, forgot about it and at some point came back to around 800 threads.

@Jkizzyfoss commented on GitHub (Jul 19, 2025): I observed this issue too, forgot about it and at some point came back to around 800 threads.

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@koffydrop commented on GitHub (Aug 13, 2025):

Same happens for me, roughly every 3 seconds a new thread spawns. I wrote a script to cross-reference the service log and thread count for the process and in fact, every time it logs INFO mpd_discord_rpc: starting drpc client, a thread spawns and persists, with a difference of 13 (threads - log lines) which seems to be the base thread count.

Here's one of the outputs of the script, from boot, before opening discord:

After opening, then closing (quitting, not minimizing to tray) discord, the thread count starts going down by 1 about every 5 seconds.

@koffydrop commented on GitHub (Aug 13, 2025): Same happens for me, roughly every 3 seconds a new thread spawns. I wrote a script to cross-reference the service log and thread count for the process and in fact, every time it logs `INFO mpd_discord_rpc: starting drpc client`, a thread spawns and persists, with a difference of 13 (threads - log lines) which seems to be the base thread count. Here's one of the outputs of the script, from boot, before opening discord: <img width="481" height="353" alt="Image" src="https://github.com/user-attachments/assets/7f3929e3-bb4d-4d3c-b266-501faf99c980" /> After opening, then closing (quitting, not minimizing to tray) discord, the thread count starts going down by 1 about every 5 seconds.

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@koffydrop commented on GitHub (Aug 19, 2025):

How are you replicating/observing this? I've tried leaving the program running with Discord closed and a reduced idle time, and seen no increase in memory.

After a bit more digging and testing, the problem occurs for me when the discord socket (/run/user/1000/discord-ipc-0 in my case) hasn't been created yet.

The connection manager logs:
ERROR discord_presence::connection::manager: Failed to connect: IoError(Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" })

I also tested https://github.com/JakeStanger/mpd-discord-rpc/pull/223 but after connecting and disconnecting once, it doesn't seem to attempt a connection again.

The drpc can't tell a difference between errors in the on_error() handler, so it can't change behavior there as far as I can tell.

@koffydrop commented on GitHub (Aug 19, 2025): > How are you replicating/observing this? I've tried leaving the program running with Discord closed and a reduced idle time, and seen no increase in memory. After a bit more digging and testing, the problem occurs for me when the discord socket (`/run/user/1000/discord-ipc-0` in my case) hasn't been created yet. The connection manager logs: `ERROR discord_presence::connection::manager: Failed to connect: IoError(Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" })` I also tested https://github.com/JakeStanger/mpd-discord-rpc/pull/223 but after connecting and disconnecting once, it doesn't seem to attempt a connection again. The drpc can't tell a difference between errors in the `on_error()` handler, so it can't change behavior there as far as I can tell.

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@JakeStanger commented on GitHub (Aug 19, 2025):

I have just tested myself and have found the same - #225 seems more reliable for me as a fix.

I'll leave it a couple of days before merging anything in case anybody finds an issue with it, but if that seems to be the consensus we'll go that way.

Thanks all for your help with this.

@JakeStanger commented on GitHub (Aug 19, 2025): I have just tested myself and have found the same - #225 seems more reliable for me as a fix. I'll leave it a couple of days before merging anything in case anybody finds an issue with it, but if that seems to be the consensus we'll go that way. Thanks all for your help with this.

JakeStanger commented

2026-05-22 22:03:43 +01:00

Author

Owner

@JakeStanger commented on GitHub (Aug 21, 2025):

Merged. I'll get a new release out now, and if there's any further problems I'll follow up with a bugfix release as soon as I can. Cheers again everyone

@JakeStanger commented on GitHub (Aug 21, 2025): Merged. I'll get a new release out now, and if there's any further problems I'll follow up with a bugfix release as soon as I can. Cheers again everyone

JakeStanger referenced this issue

2026-05-22 22:58:23 +01:00

[GH-ISSUE #35] build failed #288

JakeStanger referenced this issue

2026-05-22 23:58:31 +01:00

[GH-ISSUE #35] build failed #554

JakeStanger referenced this issue

2026-05-23 00:58:13 +01:00

[GH-ISSUE #35] build failed #820

JakeStanger referenced this issue

2026-05-23 01:58:18 +01:00

[GH-ISSUE #35] build failed #1088