[zeroibis]

OK I have an idea, what if the issue is that it does not like you setting the value to a value that it already is multiple times?

For example:

SetListenOverride(i, client, Listen_Yes);

Now what is the client in question here is already set to Listen_Yes? If this is the case then the statement above is redundant. Perhaps if we tracked who was what and avoided redundancy (there is quite a bit of this in my code) the glitch will go away...

[databomb]

That's a good idea to try. Since we have to re-do our overrides when a player spawns, the voice map array in sdktools might still show the override we used for the previous round and not reset to Listen_Default. If that's the case then the IncHookCount would get called an excessive amount of times but since it's of integer type I doubt we're overflowing in 45 minutes.

[databomb]

This is a modified sdktools extension built on Windows.. it's just easier to develop on here so I haven't made a Linux build yet to test on my own server. Attached is the modified voice.cpp file and the binary. Can anyone build this in Linux that already has everything downloaded and set up?

Changes for the voice.cpp

All the incrementing and decrementing counters are gone, VoiceServer is hooked in VoiceInit() and is never unhooked. I wanted to unhook this when the extension is unloaded but this didn't seem to be the norm in the extension so I omitted it. OnClientDisconnecting code was modified so it didn't depend on the hook counters (it's now all in the main for loop instead.)

[BAILOPAN]

databomb: Why are you changing this, and distributing builds?

kossolax: You said there was a crash "after 30 minutes", then you said it doesn't crash, so I'm a little confused now.

To be clear, if there is a problem, removing random code and not having clear steps-to-reproduce isn't a solution. It's not even clear we have definitive failure symptoms!

We can ship an instrumented binary to diagnose problems based on symptoms. I don't think it's a good idea to cut up code without understanding it, then distribute modified builds of official binaries.

[BAILOPAN]

So, let me try to summarize what the failure symptoms are and aren't:

(1) After some point in time, something about the functionality of voice.inc breaks. What, exactly?
(2) There are no crashes.

And, the steps to reproduce are still pretty fuzzy:
(3) You need more than few players, and
(4) Lots of toggling of voice settings.

(1) needs more explanation.

[databomb]

(1) needs more explanation.

In sdktools_voice.inc, SetClientListeningFlags and SetListenOverride do not function in a failure situation. Regular mutes from basecomm do not even function any longer and the server reverts to the talking mode defined by sv_alltalk. I have not investigated the GetClientListeningFlags or GetListenOverride. The only reliable way I'm aware of to restore functionality is completely exiting srcds and starting over.

I don't think it's a good idea to cut up code without understanding it, then distribute modified builds of official binaries.

You're the boss... The changes, however, weren't made randomly. The reasons for removing the voice hook counting was the lack of a reason to keep it there: Fyren stated this protects us when Valve sends an update that breaks the hook but to anyone already running one of these plugins or to anyone that even so much as mutes another player, they're affected. Changes inside OnClientDisconnect were mostly for readability. I also subsequently added a check inside OnSetClientListening to make sure the sender and receiver aren't the same person - reason being that there's no need to do the call if they're the same person.

As far as a debugging binary, it might be useful to log whenever the VoiceServer is unhooked. Other reasons why the sdktools_voice.inc functions would fail are beyond me at this point...

[BAILOPAN]

The changes, however, weren't made randomly. The reasons for removing the voice hook counting was the lack of a reason to keep it there

Thanks for your explanation and fearlessness at diving into the code

If you know the refcounting is wrong, let's fix that. If you don't know it's wrong, then "lack of a reason" does not make this a bug fix, it makes it instrumentation (which is valuable, but harder to gather data).

Fyren's right-on that we try not to hook things unless they're needed - especially for cases like this that get called many times per-player, per-frame (hooks have measurable overhead). It's defense-in-depth against many things. There's a maintenance cost in complexity, but SM tries to stay out of the server's way unless asked otherwise, I'd like to uphold that.

Anyway, I'll back off since Bugzilla is still down: let's see what the result from your patch is.

[zeroibis]

I am going to try the other way by leaving sm as is and looking into code optimizations. As my program is very redundant I am going to make it so that all redundancies are eliminated. This may then solve the problem assuming it is simply getting mad at me for setting a value to the same thing multiple times in a row. Hopefully between the custom build and trying to clean up code we can figure out which side this problem really is on.

[databomb]

BAILOPAN or Fyren, could you *pretty please* build this on a Linux machine? Release should be OrangeBox Valve for my CS:S server. My server is Linux but it'll take me some time to sort through getting all the dependencies playing nicely together before I could make my own.

This is the voice.cpp I posted earlier with the small addition of checking the receiver against the sender in OnSetClientListening:
http://pastebin.com/kEQrZ3YF

If you know the refcounting is wrong, let's fix that. If you don't know it's wrong, then "lack of a reason" does not make this a bug fix, it makes it instrumentation (which is valuable, but harder to gather data).

Agreed. Hopefully these two approaches can shed some more light on the situation.

[kossolax]

Originally Posted by kossolax I'm on linux ubuntu 10.4, and I have shell acces. But server is not crashing, so I don't know if there is a crash somewhere.

Sorry, but I was meaning, that the server it-self doesn't crash, so there is no crash repport or .dmp generated. Only the function stop working, without any error reported from sourcemod or in server console.