No Good Way to tell which is the Correct Session to Kill in http://www.buddyauth.com

[mephuser1000]

- The sessions are labelled by "Control", "Type", "Started", "Running Time".

- There's no real way to tell which is/are the real frozen one(s).

- "Started" is mostly inaccurate like roulette.

- Kill the wrong session and you're screwed -> Relogging the wrongly killed DB Window will attach it to the wrong D3 instance, or worse 2 of the same DB Windows end up attaching to the same D3 instance, ignore the incorrectly killed D3 instance.

- It is frustrating that you have to end up either killing all the sessions or wait for the "real one(s)" to expire.

 

[notsureifserious]

i know how you feel lol, i end up closing all 3

 

[Robby2x]

+1 here

 

[Lollaskates]

The battletag implementation on running processes would be fantastic for buddyauth.

 

[Kickazz006]

add running time to your taskmgr

 

[Ipo]

Having the same problem as OP, especially since it's a real pain to automate the session killing to keep the bots running during the night through crashes and whatever else might happen. I would suggest that DB use an (optional)ident key in combination with the API key when authing. That way, if the same DB auths again later, the ident key + API key will make for a unique pair, allowing the old, stale session to be killed off and replaced automagically. The ident key could be entirely optional to keep current behavior for those that don't want it, but provided via the commandline for those that do. The ident key could also double as a handy way to 'name' separate bot sessions in the sessions portal, to keep track of which session is which bot.

 

[mephuser1000]

add running time to your taskmgr

How?