Jump to content
Mumble forums


  • Posts

  • Joined

  • Last visited

Everything posted by mkrautz

  1. Did you try the suggestion of copying your Mumble install to your desktop, and running it from there? That was the main point.
  2. Hi, Thanks for your kind words about Mumble. Greatly appreciated! There's a long running thread on GitHub about this problem. I have been able to use a virtual F13 key using AutoHotKey: https://github.com/mumble-voip/mumble/issues/987#issuecomment-260461709 Could you try the approach at the bottom of my post (copying Mumble to the desktop, and running it from there?). Mumble, by default, on Windows runs in a special mode for assistive technologies, so Mumble can intercept keypresses from some elevated programs. We do this to avoid keys getting "stuck". Please report back with your findings. Thanks!
  3. I am still confused regarding the last bullet point. Are you asking the Mumble project for improved documentation on how to change the client's default settings, to easier allow you to configure the client for connecting to your HN? Or something else? I need to know more about your setup to say anything intelligent. :-) Mumble supports HTTP(S) and SOCKS5 proxies. Are you using those? Or are you using a standalone client?
  4. I've implemented this in https://github.com/mumble-voip/mumble/pull/3118
  5. Hmm, not at the moment. But it's something we could implement...
  6. Hi, We provide RPC APIs to allow you to get to the necessary data for your Murmur server. I am not aware of any "plug-and-play" solution for SMF, unfortunately.
  7. Hi, The problem is that Mumble 1.2.x in Linux distros is built against a stock Qt 4. Our official binaries (as well as some operating systems, such as OpenBSD) use a patch for Qt 4 that allows it to use TLS 1.2. No Linux distros have picked up this patch, to my knowledge. But as I said, our official 1.2.x binaries all carry the ability to negotiate TLS 1.2. If you can get a "mumble-git" or "mumble-snapshot" version for your distro, you should also be good to go, since this version is built against Qt 5, which supports TLS 1.2. Unfortunately, we only provide our static Murmur Linux binaries for x86 at present, so I don't think that's much help for you, on ARM.
  8. I think what happened is that you deleted your original certificate, and you are trying to connect with the username you used previously. If you've created a new certificate, try to choose a different username, and you should be able to connect again. Then you can re-register, and an admin can change your name, if needed.
  9. Sorry for the late response. Could you prehaps show us the output of Mumble's log when this doesn't work, and also when it does work? I'm interested in what parameters Mumble is using for the audio devices. Thanks. Your log file is available at %APPDATA%\Mumble\Console.txt
  10. I haven't tested EVE on Mac recently. I've filed this issue for the problem: https://github.com/mumble-voip/mumble/issues/3117
  11. Also filed https://github.com/mumble-voip/mumble/issues/2667
  12. This issue seems to pop up a lot. Mumble doesn't respect the chosen output device for Text-to-Speech: we simply use Microsoft's Text-to-Speech API, and whatever default output device it uses. I've filed this issue for the problem: https://github.com/mumble-voip/mumble/issues/3116
  13. Yes. Yes, but if it is a modified client, we'd prefer it if you make it clear that it's not official software from the Mumble project. What changes have you made to the software? Sure, we do all our development on our GitHub organization: https://github.com/mumble-voip What changes have you made to the client, if any, at present? How do you imagine the VPN connection would be integrated into Mumble? I'm not sure why you think it is necessary to integrate into Mumble itself, but I'm interested in hearing your thoughts. Thanks, Mikkel
  14. Development snapshots are available thorugh our website: http://www.mumble.info/
  15. Our implementation only worked on Qt 4. What we did was, we made use of our existing overlay. Then we leveraged our GlobalShortcut implementation (including the ability to suppress events). This allowed us to grab mouse coordinates, clicks, etc. -- and ensure they weren't delivered to any other app on the system. Our code is old and unmaintained, and I doubt it works well anymore. However, our implementation mirrored the "Windows platform" windows from Mumble into overlay. That was the most hacky part of it. If you instead use a custom platform plugin in Qt, or you simply draw your widgets yourself, it should be much more doable. Unfortunately, our overlay code isn't really its own project, so it's not easy to integrate into something else.
  16. Sorry for not getting back to you sooner. I've updated our own (non-CDN'd) SSL config to be more sensible. The Qualsys test now gives us an A instead. Thanks!
  17. mkrautz

    Mumble evolvement

    I think your analysis and your thoughts are correct. We're currently working hard to get Mumble 1.3.0 out the door. This release has taken us a very long time -- too long -- and Mumble development has suffered as a consequence. Once 1.3.0 is out the door, one of the things I would like to implement is a WebSocket backend: https://github.com/mumble-voip/mumble/issues/2131 A web client will allow us to experiment much more with the user interface and it would be natural to optimize such a client for a nice first-run experience. This, combined with good Let's Encrypt integration should make it very easy to self-host Mumble servers and use them without too much hassle. However, there are many UX problems with Mumble currently that I'd like to address, some of them targetted at the developer experience as well: - Non-intuitive UI for beginners - Non-intuitive client configuration - Non-intuitive authentication system - Non-intuitive permission system - Lack of a good manual for both Mumble and Murmur - Lack of good developer documentation - Lack of easy-to-use integration points for Mumble and Murmur - Lack of a Mumble SDK for developers etc. etc. Hopefully, once we have Mumble 1.3.0 out the door, we can begin ticking some of these off!
  18. There is nothing that really forces the WASAPI backend to use 48KHz. We could run it at something else, if there are compatibility issues. For many other audio backends, we let the system choose. If it deems 44.1KHz a better fit, we will use that and resample to 48KHz on the fly for internal use.
  19. mkrautz

    Development idea

    Correction: BSD license. See https://www.mumble.info/LICENSE
  20. Actually, in Mumble 1.2.x there is a full-screen overlay that does embed the full Mumble client in the overlay. We do it using various hacks in both Qt and Mumble, and it's not pretty. It's not going to function in Qt 5/Mumble 1.3.0. Some quick pointers for some of the hacks: https://github.com/mumble-voip/mumble/search?p=1&q=g.ocIntercept&type=&utf8=%E2%9C%93 and our patched Qt 4 is at: https://github.com/mumble-voip/mumble-developers-qt
  21. Hi, The referral error means there is a problem with validating the code-signing for the Mumble executable. Is the clock on your computer correctly configured? If not, the validity times for the code-signing certificate will not be valid. Where did you get your downloads from? The only place we recommend you download Mumble from is: https://www.mumble.info/ Please try both the stable release and the developer snapshot. If nothing else works, you can try following this guide: https://support.techsmith.com/hc/en-us/articles/203728788-Camtasia-Windows-A-referral-was-returned-from-the-server This disables the code-signing requirements for programs like Mumble (that use assistive technologies to access global keypresses). However, doing this can be dangerous: the reason Windows has this enabled in the first place is that disabling it makes it very easy for programs to act as a keylogger.
  22. OK, I just tried something on my local machine. I used Dependency Walker to see what jvm.dll from C:\Program Files\Java\jre1.8.0_121\bin\server depends on. And it does indeed depend on msvcr100.dll -- a MS VC 2010 CRT DLL. Since there is no msvcr100.dll next to JVM.dll, it loads the copy from c:\Windows\system32. Now... What happens on your system might be that on Murmur uninstall, the MSVC2010 CRT is uninstalled, and thus no longer available in c:\Windows\system32. That means jvm.dll is no longer loadable. The easy fix would probably be to copy msvcr100.dll from C:\Program Files\Java\jre1.8.0_121\bin into C:\Program Files\Java\jre1.8.0_121\bin\server so JVM.dll has a local copy. You can even do the above trick without uninstalling Murmur first. Just do it, and reboot, to ensure SageTV's JVM uses its own local copy of msvcr100.dll. I suppose SageTV is using jvm.dll directly, instead of using java.exe/javaw.exe? If it used those, I imagine the jvm.dll would in fact load the msvcr100.dll from C:\Program Files\Java\jre1.8.0_121\bin. (It would be required to, since java.exe/javaw.exe use that DLL.) Finally, to ensure that that is actually the case, I'd recommend finding the SaveTV process via Process Explorer (https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) to check whether the correct msvcr100.dll is loaded into the proces. Try to find the process in Process Explorer, and use the module view at the bottom of the screen to see the loaded DLLs. You should expect SageTV to be using the msvcr100.dll not from C:\Windows\system32, but instead from the JRE diretory, probably C:\Program Files\Java\jre1.8.0_121\bin\server\msvcr100.dll. Once you have confirmed that SageTV is not using msvcr100.dll from c:\Windows\system32, you should be able to safely uninstall Murmur. Hope it helps, Mikkel
  23. OK, I realize "trying" a newer version might be hard if it trashes your machine... Let me think of a better solution... :-)
  24. Murmur 1.2.8 is very old. That installer used to use "merge modules" for the MSVC2010 C Runtime. Basically, that means that every time Mumble is installed (I am not sure how uninstalls are affected), it call out to a bundled C runtime MSI file to ensure the correct C runtime is properly installed. If the JVM is built against MSVC2010 CRT that, I suppose that could affect it, somehow. That is pretty much the only thing I can think of that could potentially cause something like this. Can you try with Murmur 1.2.19 instead, and see if that installer has the same behavior?
  25. No, we haven't removed the entry on the registration server. It's odd that it counted it as a new registration.
  • Create New...