Previously, Mumble would always use the original hostname when verifying a server certificate. When the actual server hostname (resolved through an SRV record) differs from the original hostname, it should be used instead.
Fixes#3563
Prior to the implementaiton of raw mouse input, a low-level mouse hook was used for capturing mouse events. Windows would emit a single WM_* event per button state change. With the move to capturing raw mouse input events, it was expected that this behavior remained, despite now needing to listen for WM_INPUT events.
However, unlike when using the low-level hook, WM_INPUT events can contain data for multiple simultaneous mouse state changes. If this occurred, Mumble would register none of the state changes.
Changing the logic to account for multiple state changes in a single event correctly allows for all states changes to be registered.
Fixes mumble-voip#5706
CodeQL Action v2 was released 2022-03-30.
Deprecation of v1 is scheduled for December 2022. [1]
Fixes a CI warning.
[1] github.blog/changelog/2022-04-27-code-scanning-deprecation-of-codeql-action-v1
Although installing MFC is mentioned in setup_visual_studio.md,
identifying where the header file is expected from is not obvious.
A C++ environment may already be installed without MFC, where the VS setup docs may not be followed/opened before-hand.
Without the change mumble build fails on this week's gcc-13 snapshot as:
plugins/Module.h:13:9: error: 'uint64_t' does not name a type
13 | typedef uint64_t procptr_t;
| ^~~~~~~~
plugins/Module.h:12:1: note: 'uint64_t' is defined in header '<cstdint>';
did you forget to '#include <cstdint>'?
11 | #include <unordered_map>
+++ |+#include <cstdint>
12 |
Co-authored-by: Davide Beatrici <github@davidebeatrici.dev>
n the 1.4.230 release, we enabled RNNoise by default as there have been
lots of reports of how well it works. However, after the release we saw
numerous reports complaining about bad audio quality, which was traced
back to having RNNoise enabled.
For some reason the outcome of having RNNoise enabled is very different
in different scenarios. Sometimes it works miraculously well and other
times it worsens the audio quality to an unbearable level.
There seems to be a higher chance of RNNoise messing up, when using
Windows, but the same effect has also been observed on Linux. It might
also depend on the quality of the used microphone (better quality = less
noise -> RNNoise starts doing weird stuff), but we don't have any
definitive clues yet.
Because of this, we will change the default noise cancelling mode back
to Speex so that everyone for whom RNNoise actually works, cna enable
it, but we don't kill the experience for many folks by using an
unsuitable default value.
Fixes#5448
In the 1.4.230 release, we enabled RNNoise by default as there have been
lots of reports of how well it works. However, after the release we saw
numerous reports complaining about bad audio quality, which was traced
back to having RNNoise enabled.
For some reason the outcome of having RNNoise enabled is very different
in different scenarios. Sometimes it works miraculously well and other
times it worsens the audio quality to an unbearable level.
There seems to be a higher chance of RNNoise messing up, when using
Windows, but the same effect has also been observed on Linux. It might
also depend on the quality of the used microphone (better quality = less
noise => RNNoise starts doing weird stuff), but we don't have any
definitive clues yet.
Because of this, we will change the default noise cancelling mode back
to Speex so that everyone for whom RNNoise actually works, cna enable
it, but we don't kill the experience for many folks by using an
unsuitable default value.
Fixes#5448
We used to use a self-hosted macOS CI runner but since we were only
using that for Nightly builds, we frequently ran into situations where
some issue was only appearing there which meant that while for the PR
the CI succeeded, it would fail after the change had been merged in.
As this is not a desirable situation, this commit makes sure that we are
using the same macOS runner for all CI runs. For simplicity we are using
the Azure hosted ones for that purpose.
We used to use a self-hosted macOS CI runner but since we were only
using that for Nightly builds, we frequently ran into situations where
some issue was only appearing there which meant that while for the PR
the CI succeeded, it would fail after the change had been merged in.
As this is not a desirable situation, this commit makes sure that we are
using the same macOS runner for all CI runs. For simplicity we are using
the Azure hosted ones for that purpose.
f999081 enabled the MySQL plugin for Qt.
Turns out its master dependency (libmysql) cannot be built for x86:
microsoft/vcpkg#11214
This issue leaves us with two choices:
Get rid of x86 builds altogether.
x64 builds with MySQL plugin, x86 ones without. Potential confusion.
We asked on our Matrix channel whether anyone used official x86 releases.
Nobody did, which is a very good thing considering x86 (32 bit) CPUs are no more.
In addition to that, Microsoft dropped the platform with Windows 10 2004.
f999081ab8 enabled the MySQL plugin for Qt.
Turns out its master dependency (libmysql) cannot be built for x86:
https://github.com/microsoft/vcpkg/issues/11214
This issue leaves us with two choices:
1. Get rid of x86 builds altogether.
2. x64 builds with MySQL plugin, x86 ones without. Potential confusion.
We asked on our Matrix channel whether anyone used official x86 releases.
Nobody did, which is a very good thing considering x86 (32 bit) CPUs are no more.
In addition to that, Microsoft dropped the platform with Windows 10 2004.
If the osxdist script was not executed within the build directory, it
would not bundle the built plugins (most notably the Link plugin) as it
was using a relative path and was ignoring the binary dir command-line
option.
This is remedied by this PR.
Fixes#5571
If the osxdist script was not executed within the build directory, it
would not bundle the built plugins (most notably the Link plugin) as it
was using a relative path and was ignoring the binary dir command-line
option.
This is remedied by this commit.
Fixes#5571
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.9% (2087 of 2088 strings)
Co-authored-by: Alexey Dobrovolsky <dobrovolskiy.alexey@gmail.com>
Co-authored-by: Game one <denis.melnyk.2006@gmail.com>
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Konstantin Goncharik <botankras@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/ru/
Translation: Mumble/Mumble Client
