Presence updates hang my game about discord-presence HOT 34 OPEN

Hey sorry or the late reply, I'll take a look in my own environment quickly.

from discord-presence.

I did my best to re-create this in my own environment, but it did not introduce any problems for me.

Could you list the following information:

• OS (eg. Windows 10)
• Build target (if not the same as host OS)
• Rust compiler version (eg. rustc 1.60.0 (7737e0b5c 2022-04-04))
• Rust toolchain (eg. nightly)

from discord-presence.

Do you get this error per chance (should print in the console where you ran the app):

Failed to connect: IoError(Custom { kind: TimedOut, error: "timed out while reading from pipe" })

from discord-presence.

OS: Windows 10
Rust: 1.60.0 stable
Target: same as build environment

No connection failures. I just experience hangs whenever I uncomment any code that updates my activity.

I'll slap a few printlns in the plugin code in the next day or two and see if I can track down the moment when it hangs.

from discord-presence.

Okay, let me know if you make any progress. I'm sorry I can't be of more assistance

from discord-presence.

Closing for inactivity. Please re-open or open a new issue if you experience the problem again.

from discord-presence.

Sorry for the delays, had some PC issues and needed to get caught up on other things before digging into this.

I've done a bit more digging. I've sprinkled some println!s around the code. It seems like the initial presence set goes through quickly. Subsequent sends hang for a while before responding, though they do eventually go through. The Discord responses don't appear to be errors, they just take a long time to return. Further, there's a pretty large CPU spike. I don't see anything useful in the console other than the messages I've added.

The specific place where the delay seems to happen is here:

        println!("Sent");
        let Message { payload, .. } = self.connection_manager.recv()?; // hang
        println!("Received {:?}", payload);

I'm not a networking expert and certainly don't know much about interfacing with Discord, but you have a send_and_receive function that appears to be interfacing with crossbeam channels, but ultimately it calls socket.recv() which, according to its docs, makes no guarantees about whether or not it blocks.

You're also spawning send_and_receive_loop on another thread and locking the connection. Is there anything else that needs to hold this lock? I'm wondering if it should be dropped before the sleep call to avoid deadlocks, but if nothing else needs it then it wouldn't matter anyway. Adding that didn't make a difference here--I'm just stuck on that socket.recv call that makes no guarantees about whether or not it blocks.

Let me know if there's anything else you'd like me to try.

from discord-presence.

Er, actually sorry, it's std::io::Read::read, not recv. Sorry, screen reader user and too many similar-sounding short words.

Anyhow, I've confirmed that the read call in Connection::recv blocks, at least here. Given it's called in a function managing crossbeam channels, I suspect that's undesirable behavior. :)

from discord-presence.

OK, sorry, one more and I'm done for the day. :)

In WindowsConnection, you set a read/write timeout of 30 seconds. Curious why these values are so high? Would it be better to make these values lower so the read call doesn't block, then silently eat the timeouts in send_and_receive?

If I set the value to 1, I get a bunch of timeouts logged. So maybe my Discord client responds slower, but read timeouts on my end are looking like the cause. Maybe presence updates are rate-limited?

Sorry again for all the noise on this issue.

from discord-presence.

Er, actually sorry, it's std::io::Read::read, not recv. Sorry, screen reader user and too many similar-sounding short words.

Anyhow, I've confirmed that the read call in Connection::recv blocks, at least here. Given it's called in a function managing crossbeam channels, I suspect that's undesirable behavior. :)

Good catch :)

(I believe), the recv call was blocking the active thread until something came through, creating your hanging issue.
Could you check-out the fix/recv branch and let me know if that version fixes your issue? As I have been unsuccessful in re-creating it on my end.

In WindowsConnection, you set a read/write timeout of 30 seconds. Curious why these values are so high? Would it be better to make these values lower so the read call doesn't block, then silently eat the timeouts in send_and_receive?

In all honesty, I didn't write most of the base code for the RPC library, I borrowed it from an older library and adapted it to work better with the newer Rust ecosystem, and interact nicely with Bevy. There are a lot of things I am still looking to change in the base library, mostly just a lot of refactoring.

Regardless another good catch, I'll lower those values because we certainly don't want it waiting 30 seconds for a connection that will never arrive.

Sorry again for all the noise on this issue.

Don't apologize it's helpful to have feedback, realistically I can't fix an issue if nobody talks to me about it so thank you for being active :)

from discord-presence.

crates\rpc\src\connection\manager.rs:56 should be time::Duration.

It no longer hangs, but I still get timeouts. I suspect what should happen is that the timeouts on read shouldn't be errors, they're just a condition of the read blocking. Also, should 0 bytes received be classified as connection loss, or just an empty read?

Thanks for digging into this.

from discord-presence.

I suspect what should happen is that the timeouts on read shouldn't be errors, they're just a condition of the read blocking.

Yes and no.

True that they shouldn't exit the program (which I believe they don't), but they are a case where we have sent a message without a response which isn't supposed to happen, I don't believe.

What I will do for now, is change the log to debug rather than error so that it won't show up in production builds and shouldn't be as annoying. I'll keep looking though and try and work out the structure.

from discord-presence.

from discord-presence.

Apologies for the late response.

Could you check the updated version of the library and see if that fixes any of the issues you were having?

from discord-presence.

from discord-presence.

discordjs/RPC#14 (comment) Not sure if that particular field is being included, but it seems like removing it helped in some instances.

from discord-presence.

Not sure if that particular field is being included

By default, it shouldn't be. If the developer sets show_time to true, then it does, in order to display the time in Discord but otherwise it doesn't.

from discord-presence.

If you delete Cargo.lock and re-install dependencies, it should update the base library version to 0.5.5 which should fix the logs

from discord-presence.

Sorry for the delay. Doesn't appear as if 0.5.5 is released.

from discord-presence.

My bad. Should be published now

from discord-presence.

@ndarilek Any updates?

from discord-presence.

Sorry, looks like I replied via email but the comment isn't listed here. On July 8 I wrote:

Ugh, still just reports multiple timeouts.

Thanks for looking into this, not sure what else to recommend.

from discord-presence.

That's unfortunate. If you could try it again with v0.5.6? It fixed the issue with #12 which may be unrelated but worth a shot I guess.

from discord-presence.

Same log message, but now the game hangs again and doesn't launch. :( Maybe it'd time out eventually but I didn't wait.

from discord-presence.

Hey sorry for the late response. I think I am finally able rto recreate the issue on my local environment, so I can finally properly get to fixing it. I will update you asap.

from discord-presence.

Hey, I think I may have finally fixed the issue in #20. If you could test it for me that would be great thanks :)

from discord-presence.

It does seem to hang a lot less, though there are occasional spots where the game loop still gets stuck which may correspond to places where updates happen. I'm trying to investigate whether or not I'm being rate-limited or similar, since it's always in my menus and not in the same place. But yes, I now have the plugin enabled because at the very least I can play the game and not have it hang.

I have the following in Cargo.toml, hopefully this is the right dependency combination:

bevy-discord-presence = "0.3"
[patch.crates-io]
discord-presence = { git = "https://github.com/jewlexx/discord-presence" }

Going to do a bit more debugging of the remaining hangs, and will report back what I find.

from discord-presence.

I have the following in Cargo.toml, hopefully this is the right dependency combination:

bevy-discord-presence = "0.3"
[patch.crates-io]
discord-presence = { git = "https://github.com/jewlexx/discord-presence" }

That's perfect. I have published the blocking patch but until it is fixed altogether, if you could stay on the github branch that would be great thanks.

It does seem to hang a lot less, though there are occasional spots where the game loop still gets stuck which may correspond to places where updates happen.

Glad to hear it is hanging less, I will dig through the updates code and I am considering working on a built in rate limiter, which queues executions until the rate limit is refreshed, as currently it is very easy for developers to hit the rate limit by accident.

from discord-presence.

from discord-presence.

Hey @ndarilek I am currently working on a patch that will use websockets rather than native sockets, which might fix the issues you were having. It's not close to being done but you can track progress here: #28

from discord-presence.

This issue has been marked as stale

from discord-presence.

Finally getting time to circle back to this.

Were the websockets changes ever merged?

Re-enabling the released version of the plugin in my game now gives this message in addition to the others I've seen:

2023-01-09T14:31:59.151109Z ERROR bevy_discord_presence: Failed to set presence: Connection has not been started

And then I get the usual hang.

Thanks.

from discord-presence.

No sorry websockets were never merged, I never finished working on it. I've spent a long time away from this library.
The Connection has not been started is related to #37.
I will continue working on websockets ASAP.

from discord-presence.

This issue has been marked as stale

from discord-presence.