@deterministic_bubble sorry for the ping, I am yet new with Discourse quoting.
Curious. Maybe we’re violating a protocol spec somewhere still?
Were you using a Murmur 1.4 branch version?
Nope, I was running stable 1.3.0.
Re-tested it today to remind myself what was wrong and to provide more sofisticated details since I wrote it as extra case and… targets work fine - at least player ones, but game client does not create any channels at all (neither temporary or static), ACL’s adjusted of course.
What else I’ve forgot to post (keyword: violation - thanks for reminding!), when connecting classic Mumble client 1.3.3 to FXServer built-in Mumble, sometimes you get protocol violation error:
It would be cool to protect the built-in server with any authentication, since now anyone can connect with any client and do actually bad things.
That’s curious. Define a ‘voice loss’ here?
What does and doesn’t happen in such a case? Packets are piped through the exact same way, so it’d be confusing for whatever issue with packet handling to happen more frequently with native audio enabled.
Still working on collecting data for this. One of our administrators occured this during night after I’ve asked for data collection, so I’ll post what I got for now:
- complete randomness, I don’t know yet how to reproduce it, since he was walking for 2 hours talking and then voice just stopped working
- he made a full dump, since yesterday I didn’t pass information about ETW tracing: https://drive.google.com/drive/folders/1nvdwUSXiiEcNSuFxtLgMXWvb0HEs8cLX?usp=sharing
- what he discovered, is that his ped model had no face animation even when he talked, so it seems the game client didn’t detect any voice
I’ve asked once again, to test for us is ‘talking’ flag passed and to collect pcaps from client that isn’t heard and from client that isn’t hearing.
What interior, for example? I asked earlier in this topic and didn’t get any feedback on that.
Test case: hei_dlc_heist_police aka police building at Mission Row.
Dumps are not really what one needs for ongoing issues, they’re just as last resort for ‘stuck’ states.
If a ‘spike’ in this case means ‘a stutter/hitch/… of the full game’, or ‘voice stuttering while seeing a CPU use increase’, an ETW trace while such is going on (of the client) would help more. Usual caveats apply: fast sampling, trace to file, not circular buffer, and trace for 20-30 seconds max.
Naming it correctly: around 1 second hitch (complete client freeze).
We shall have ETW traces for this today.
This was an external PR, so it might have inherent issues in its implementation.
Is this reproducible even without any players, say, by repeatedly switching servers? It might be the PR forgot to reset some state somewhere or such.
Not sure, going to test it as the last thing. You can surely reproduce it at our environment.
This is a known issue but mostly tangential to the aforementioned.
Still, shouldn’t it silently abandon reconnection if there’s no game session?
Will come here back within 6 up to 8 hours with more data.