Events occasionally do not fire (ClientLeftView,ClientEnterView,TextMessage)

[nikeee]

Events occasionally do not fire (ClientLeftView,ClientEnterView,TextMessage)

[Arefu]

It also might be apparently disconnecting if idle for to long? Is this a server setting that times them out, or since I'm not doing a whoami loop to stay conected?

[nikeee]

The server disconnects an idle client. See: #7 (comment)

[Arefu]

Hmm, I do think it's a "bug" but, only because TeamSpeak themselves have made it one, I think the Connect or even Login function should accept an overload for Stay Alive, so it just sends a Who Am I every 5 seconds or so just to stay awake.

I'll hack that in my project, see if it fixes it, if it does I may submit a PR :)

[nikeee]

How about a separate class that takes a Client and sends heartbeats? Something kile this:

class HeartbeatSender {
    HeartbeatSender(QueryClient client) { ... }
    void StartHeartbeats() {}
    void StopHeartbeats() {}
}

TeamSpeakClient c; // ...
var hb = new HeartbeatSender(c);
hb.StartHeartbeats();

Alternatively, we can build this right into the QueryClient. I don't know what the better approach would be.

Any pros and cons of both approaches?

[Arefu]

Hmm, the overload idea could work, you could hook it up to a stopwatch behind the scenes for every X seconds specified by the user with a default of 3 so it just sends a who am I?

That's at least what I am going to test with my project now, also any reason why TeamSpeakClient.Client.IsConnected would be false right after calling Connect? Do I need to really await everything in order for it to connect fully?

[Arefu]

Hmm, one caveat may be that if we do a keep alive style it may just get stuck waiting for that to finish then just keep stacking up other events which cause that to dead lock, or have I fallen off my rocker

Also, I'm now I'm not getting any events again for messages recieved, I have not been idle and IsConnected is true?
(I can't get code tags to work >:(, but this is the code I have to set every thing up and try register for events, I've also had the RegisterServer and RegisterTextServer notificatioons above the Subscription of events, ServerID is correct as the server has not changed and has worked previously with what I use.

 KeepAlive = new System.Timers.Timer();
 KeepAlive.Interval = 3000;
//KeepAlive.Elapsed += KeepAlive_Elapsed;
            
//Setup Instance, Connect and Login
Instance = new TeamSpeakClient(Host, Port);
Instance.Connect();
Instance.Login(User, Pass);
//Select Server & Set Nick
Instance.UseServer(ServerID);
Instance.ChangeNickName("Bitch");
//Setup Callbacks For My Events
Instance.Subscribe<ClientEnterView>(ClientEnter);
Instance.Subscribe<ClientLeftView>(ClientLeft);
Instance.Subscribe<TextMessage>(OnMessage);
//We Want Server & Server Text Events
Instance.RegisterServerNotification();
Instance.RegisterTextServerNotification();
//We're Ready!
Util.Log(Util.Source.TeamSpeak, "TeamSpeak Ready.");
Ready();
KeepAlive.Start();

[Arefu]

So I rewrote it all in async using this as a point of reference and events seem to be firing now, now sure if coincidence with the time taken to rewrite to lift some rate limit, but either way it works.

I'll report back if I see it get booted for being idle, if so I'll try the Timer elapsed way and let you know.

[nikeee]

Your code misses await keywords.

Having a Timer under the good would require a specific dependency that the library user might not have (and doesn't want to install, just for having a Timer).

I think the more appropriate way of implementing the heartbeat is adding a timeout for some task in the response queue.

[Arefu]

Yeah, I figured I could get away with not, like I said, I ended up writing using async and events now work (whoo!) but I still get timed out when not active.

I used the System.Timers.Timer() class (which I'm pretty sure is in .net core so we don't have to worry about people not having the dependency), but it seems that events don't fire with it running, I'm not sure if I'm whack, or I'm doing something wrong, but it appears stuff might get caught in the queue among other things if the timer has elapsed before it fires again

[nikeee]

I opened a new issue regarding the timeout feature: #65.