[Discussion] TeamSpeak 3 Client 3.1 [BETA]

Printable View

Show 40 post(s) from this thread on one page

August 21st, 2016, 06:27 AM
Jomant

Special symbol crashes Client returns

The special character Client Crash returns in. 3.1 Beta. Here There symbol that you guys can make a Hotfix. ***LINK REMOVED***

The Android Beta Client 3.1.0 16 Aug 2016 doesn't have any issues with that symbol and doesn't crash, just the Win and Linux clients.

:-* Jomant
August 21st, 2016, 08:44 AM
Barungar

Quote:

Originally Posted by Sebi94

It's still the same config and output as I've attached a few posts before.

So you didn't disable the IPv6 on interface 10? You will have the teamspeak connection issue with longer connection times AFAIK as long as there are "valid" IPv6 adresses on your system. Because those IPv6 adresses tell the IP stack to try any measure with IPv6 first before doing a fallback to IPv4.

I suggest to any user to disable both tunneling devices windows has active in default config, teredo and isatap. In nearly all cases they so more harm then good.

I'm running a "clean dual stack IPv6/IPv4" configuration on all my devices since about 2009 and never had any such problems.
August 21st, 2016, 11:47 AM
Alpix

Client 3.1 Beta Crash (" weird unicode characters")

The old "Bug" returns.
characters: ***CODE REMOVED***

Fix: I think you know how to fix it.
FAST Fix ***LINK REMOVED***
TS³ 3.1 Beta 64
Windows 10

Have a nice day!
August 21st, 2016, 12:02 PM
ScP

Quote:

Originally Posted by Barungar

So you didn't disable the IPv6 on interface 10? You will have the teamspeak connection issue with longer connection times AFAIK as long as there are "valid" IPv6 adresses on your system. Because those IPv6 adresses tell the IP stack to try any measure with IPv6 first before doing a fallback to IPv4.

I suggest to any user to disable both tunneling devices windows has active in default config, teredo and isatap. In nearly all cases they so more harm then good.

I'm running a "clean dual stack IPv6/IPv4" configuration on all my devices since about 2009 and never had any such problems.

Sebi94 already said that it's working properly after disabling the Toredo tunneling adapter like I suggested.

I still consider this a bug as we should not try to resolve AAAA records when the only IPv6 address assigned to your interfaces is a Toredo address (prefix 2001:0000:/32).

Quote:

Originally Posted by Alpix

The old "Bug" returns.
characters: ***CODE REMOVED***

Fix: I think you know how to fix it.
FAST Fix ***LINK REMOVED***

TS³ 3.1 Beta 64
Windows 10

Have a nice day!

We're aware of the issue and we'll fix it with the next pre-release.
August 21st, 2016, 10:16 PM
skill1917

Yeah TeamSpeak definitely should not try to connect over Teredo as it is mostly broken or really bad. Thanks for all the interaction between devs and users btw!
August 21st, 2016, 10:24 PM
numma_cway

Quote:

Originally Posted by Ali1610

So I won't be able to connect to e.g. abc.belogy.de:9900 or xyz.ts3.vc anymore with TS 3.1? So the people who bought the server will have to change their bought TSDNS package to allow TS3.1 users to connect again?

If said domains run TSDNS or SRV TSDNS and the second-level domain doesn't have SRV TSDNS or the server serving the website is running a TSDNS server - yes, you won't be able to connect to these. As I said, A RR still works for higher levels, so does SRV TS3.
August 22nd, 2016, 01:36 AM
BigBear

Hello,

So, once again, I come with my question: Is there a reason for the added characters in the TSDNS client request or is it an error?
I still need an answer from the Teamspeak staff to have a correction of the JTSDNS server.

Details of my question on page 2: http://forum.teamspeak.com/threads/1...310#post434310

Thanks
August 22nd, 2016, 05:29 PM
absence

Quote:

Originally Posted by BigBear

Hello,

So, once again, I come with my question: Is there a reason for the added characters in the TSDNS client request or is it an error?
I still need an answer from the Teamspeak staff to have a correction of the JTSDNS server.

Details of my question on page 2: http://forum.teamspeak.com/threads/1...310#post434310

Thanks

The protocol got _extended_ (not changed) to identify client capablities (ipv6 primarily, to decide about the reply format). Hence, the new TSDNS allows for both request types.
For now, only those two types of requests are valid.
August 23rd, 2016, 01:20 AM
fspower

Quote:

Originally Posted by Apelli

Will the "connecting to myTeamSpeak" feature be optional?
Actually, what I like about teamspeak is it's "standaloness", unlike Skype, and small usage of RAM.
I have installed client a very long time ago, and since never had a single need to port my Teamspeak client settings anywhere, so this obsession with cloud is not clear to me...

Would be happy as a newborn, if it was possible to use chat in-game without 3rd party overlays.

I hope so. Not needing an account was always good in Teamspeak. I don't use that many different servers, so the new feature will be of little use to me. It is usually also faster to just give yourself server admin or via a friend on the server then to login with your long forgotten credentials to your MyTS account.
August 23rd, 2016, 09:38 AM
ScP

Quote:

Originally Posted by fspower

I hope so. Not needing an account was always good in Teamspeak. I don't use that many different servers, so the new feature will be of little use to me. It is usually also faster to just give yourself server admin or via a friend on the server then to login with your long forgotten credentials to your MyTS account.

The My TeamSpeak feature is (and will always be) optional. We'll still try to add new and innovative feature that make you want to use this stuff.

:rolleyes:
August 23rd, 2016, 10:25 AM
Chris

Quote:

Originally Posted by Apelli

Will the "connecting to myTeamSpeak" feature be optional?
Actually, what I like about teamspeak is it's "standaloness", unlike Skype, and small usage of RAM.
I have installed client a very long time ago, and since never had a single need to port my Teamspeak client settings anywhere, so this obsession with cloud is not clear to me...

Would be happy as a newborn, if it was possible to use chat in-game without 3rd party overlays.

Yes the MyTeamSpeak Feature is optional. You can either use (some of) its features or not, it's up to you.

Quote:

Originally Posted by RedPuma

The plugin callback

Code:

requestHotkeyInputDialog(const char* pluginID, const char* keyword, int isDown, void* qParentWindow)

doesn't work properly anymore for my addon (it was working before the update).
The Dialog itself behaves as usual (shows pressed buttons and disappears when you let go) but the settings aren't saved properly anymore. After I set a hotkey via that function it is actually added to the global teamspeak hotkey list, but the right column ("Action") appears empty. When I then press the hotkey nothing happens, my addon doesn't receive the hotkey command. When I set the hotkey via the global teamspeak hotkey menu it works. I am calling requestHotkeyInputDialog with the proper PluginID and a keyword previously registered in ts3plugin_initHotkeys.

Will look into that, thanks for report.

Quote:

Originally Posted by Jonybat

Question regarding the ongoing changes to SRV in the server and client...Is it going to be compliant with the spec in terms of priority? More specifically, regarding the client connecting to a lower priority server if the higher priority one is down.

The client should properly respect different priority records and attempt to connect to them in a standards compliant order until a connection was established.
August 23rd, 2016, 11:05 AM
Barungar

Quote:

Originally Posted by Chris

The client should properly respect different priority records and attempt to connect to them in a standards compliant order until a connection was established.

To me it seems the client also honors RFC2782...

Quote:

A Target of "." means that the service is decidedly not available at this domain.

Can this be confirmed? In my client log I see that the client states, that the SRV TSDNS resolv was succesful, the host field is shown as empty. And the client seems not to attempt to do any other tsdns related resolves.
August 23rd, 2016, 02:44 PM
Jonybat

Quote:

Originally Posted by Chris

The client should properly respect different priority records and attempt to connect to them in a standards compliant order until a connection was established.

I havent tested it recently, but I've described what I'm talking about here:
http://forum.teamspeak.com/threads/1...338#post423338

Has/will anything change in that matter?
August 24th, 2016, 11:28 AM
RedPuma

Another Plugin Callback Error

I have to report another plugin callback error:

The function

Code:

void ts3plugin_onEditCapturedVoiceDataEvent(uint64 serverConnectionHandlerID, short* samples, int sampleCount, int channels, int* edited)

is called with wrong values for the parameter 'channels'. In mono channels it is 2 and in Stereo (aka Opus Music) Channels it is 1. In the old version it was the other way round, which makes much more sense ;)

/Edit: it's not always exactly the wrong way round but the parameters of that function are most certainly broken.
August 25th, 2016, 11:24 AM
dante696

Thank you for sharing that information.
I've forwarded it to our developer.

Show 40 post(s) from this thread on one page