A post was merged into an existing topic: Ts3 3.6.0 addons incompatible
I am pretty sure I just set it ‘again’ (after disabling it before) in 3.5.6 …
(current / new workaround I use is using the Beta 5 Client, because it ignores the Master password)
You did set the master password in this release from yesterday and this on stopped working immediately?
This is fine here.
TS5 client does use another client database. This is why it does not care about that password at all.
3 Likes
Do you have Microsoft Teams or other apps with virtual audio cards installed (Mac OS > System Settings > Sound)?
You have a device from Microsoft listed in your logs. I do not see a device on my Macwith MS Teams installed or running but can choose it in the client.
1 Like
I have MS Teams installed, but no Microsoft Devices in System>Settings>Sound. There are 2 Airplay Devices as Output and a Virtual Mic from the Hue Sync App however.
Philips Hue virtual audio device is know that it can crash the Mac client.
We had the topic here
Currently we do not have a solution for this crash.
2 Likes
Cool update!
Is it possible for the bundled QT library on Linux to use the system’s default theme?
I’m using a theme engine to get a unified look for QT and GTK apps, but the QT library shipped with Teamspeak seems to ignore the theme engine 
.
https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications#QGnomePlatform
1 Like
! Plugin API increased to 26 as workaround for Qt update incompatibility
How can I release an update of my plugin, when there is no SDK update?
1 Like
Interesting, so why is it running with 3.5.7 Beta? 
The new API version is mainly because plugins need to be compiled against the newer version of Qt used.
Tha API itself has (apparently) not changed since version 24. But since the last release was for 23 you need to use the repo itself.
2 Likes
After going back to 3.5.6 when I first ran into this problem, I also reactivated the master password.
This means I had the master password from 3.5.6, then yesterday the update was shown and I chose to update (of course). I cannot login with 3.6.0, so something is not working with the encryption of my (3.5.6) master password, and going back to 3.5.6 is not possible either… (while I understand why going back might not be possible, the situation now seems to be worse than in the beta).
Best regards
Since the update to version 3.6.0, I and at least one other person I know see their own badges, but other users do not see them. Only when you manually save the badges again in the settings are they visible to other users. Do you know anything about this?
We believe that you have a problem with the master password.
But following doesn’t fit.
This can’t be the case because the beta 3.6.0 you had (from may 11th) before did not work with password from 3.5.6.
But if you had the beta 3.6.0 (from June 13) then the master password from 3.5.6 should work . Same as in this stable release.
I know these releases may confuse a bit but we believe the password was set in the 3.6.0 from may.
Could that be?
Solved
With a workaround during the Beta from May the master password would not work with latest stable.
When password was set in 3.5.x and client was updated to 3.6.0 this issue can not be reproduced.
1 Like
Had not experienced such issue with my clients so far.
Do you still client log where this happened (i mean the one before you saved them again).
Should be the first client log starting with client 3.6.0.
1 Like
I have the log files, but there are no errors or other entries about myTS/Badges. Are you looking for something specific?
But I have found out one thing: The problem only occurs with servers that have auto connect activated when TeamSpeak starts.
If the connection to a server is established quickly at launch, the badges are missing.
If the connection takes a few seconds at launch, the badges are there.
Perhaps a problem with the introduction of the new myTS push service?
disconnected from push system can be found in the log before the connection to a server where auto connect is activated and the connection only takes a short time.
I reactivated the master password on the version I was using until this Monday (whichever it was, any way I can check this?).
I also remember the workaround to get to beta 3.6.0 in May: “Workaround: Disable master password in 3.5.6, update to 3.6.0, enable master password.” That’s what I did at the time.
But I thought I had gone back to 3.5.6, because I wanted to be able to test the update again later when you bring up a new release.
That’s it. I can reproduce this that way.
Thank you.
By checking the logs and the client version in it. But you must remember when you did set the master password.
3 Likes
