Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I believe 1.1.1 is more or less "feature complete" now. I'd appreciate it greatly if Win32 people could test the latest snapshot and say either "mm-hmm" or "nah-ah", especially if you've had troubles with 1.1.0. For Linux people, it's compile time again.
Any chance to get it compiled for Win32? As far as i see it's still not on website and i'd like to test is on one of my users ;-)
Got it and I'm running my dedicated snapshot test server now.
There's one problem I just remembered that has been around I think since the beginning of the server browser. The server browser needs a refresh button. Right now I don't know of any effective way to refresh the list without restarting Mumble. In either 1.0.0 or 1.1.0 (or both), the list sometimes messed up when going away from the server browser and going back; I remember a result of that showed only two servers when I know there were several more.
Aside from that I can't think of any other issues that I haven't already reported. I'll mostly be testing that server audio issue that you say you've added a workaround for. I'll let you know the results of my testing and if I find any other bugs.
Updating the server list requires a round trip to the server, so to avoid server load there will be no refresh button.
The "back and forth" bug has been reported and (hopefully) fixed. If you can verify it's still present, let me know.
Maybe you could restrict refreshes to once an hour or something. Usually the only times I want to refresh it are long after I started Mumble, and the server list can change a lot in that time especially after a new version was released. Sometimes I leave Mumble running for weeks on end and I'd want a recent list of servers when I take a look at the server browser.
If not a refresh button then maybe something that indicates the date and time when it was loaded.
I just spotted one problem on Murmur. This is only on the Nov 6 snapshot as far as I can tell, I haven't seen this anywhere else in the logs.
I have the port in murmur.ini configured to 64737 because my main server uses the default, but it appears to me that it's still trying to use the default port. I'm not sure why it initially says it's listening on the correct port and then tries using the default.
<W>2007-11-08 00:24:56.711 1 => Server listening on port 64737
<W>2007-11-08 00:24:56.861 2 => Server: TCP Listen on port 64738 failed
<W>2007-11-08 00:24:56.971 2 => Server listening on port 64738
<W>2007-11-08 00:24:57.071 2 => Failed to bind UDP Socket to port 64738
I don't have any trouble connecting to the server on the assigned port, so this might not be much of a problem, but I'll let you decide that.
You have two virtual servers defined. One at 64737 and one at 64738.
Ah, you're right. I think it was the previous snapshot I used that I was trying to figure out multiple virtual servers. I added a second one in the servers table of the database and then realized I didn't know how to define the port for the additional virtual servers, so I stopped trying and didn't remove the new record. Sure enough, a search of the log (I don't know why I didn't do it before) showed that the messages have appeared before.
Do I add the additional ports in the ini with something like "port2="?
It might be simpler to include a port field in the servers table and when the port for server 1 is defined it overrides the ini setting. Keep the ini port setting so it's easy for people who don't want to mess with the database and only want to run one server. Then again if I'm just missing the additional port settings, I'd like to know where they are.
Looks like I have a lot to learn if I'm going to run Murmur the way I want to run it. I know almost nothing about using D-bus or Perl (being a Windows user should indicate that fairly well).
Found a crash bug in the November 6th snapshot.
Connect mumble to a murmur server.
Select Audio >> Statistics from the menubar
I'm unable to replicate this, and I'll need a bit more info.
Is this with ASIO or DirectX as Input?
Which audio card?
Does the dialog even pop up before it crashes?
This is using a Sigma Tel audio card in a Gateway M285-E laptop.
The settings are Default DirectX.
The dialogue box doesn't even pop up.
Could you cut&paste the crashlog from console.txt?
I'm not seeing such a file in the Program Files\Mumble directory.
If you provide some info on your dev setup in Windows, I can set that up here and debug. Computer Sciences is my Masters. :)
You don't have a Console.txt?
Does your user have write privileges for that directory?
And what OS are you running?
I've installed the Nov snapshot as Administrator, but I run Mumble as a regular user. From what I can see, there is no console.txt file anywhere. Regular users do not typically have write access to C:\Program Files, unless accessing a service that is running at an elevated level.
This is running on Windows XP.
If you run it as an administrator, or at the very least from a working directory you do have write privileges in, it will create a console.txt which has a crash log.
Or login as administrator and give your user account write access to the mumble folder.
Found this bug while testing the "silence problem" with TCP mode.
Murmur freezes apparently when a client on the same system as the server, after transmitting, disables TCP mode while connected or disconnects with TCP mode enabled, or sometimes when enabling TCP mode while connected. There appears to be some other possible triggers but I haven't been able to determine any exact procedures. Audio still goes through but controls (such as changing channels) don't. The non-responding front end includes the log window, the log itself (it stops right before the event that triggered it), and the task bar icon. It is similar to the "silence problem" where I haven't been able to determine exactly what triggers it but I could easily reproduce it.
In Windows, the server seems to just stop sending UDP every now and then. People can log in, but no sound is being relayed.
I'm thinking it might be associated with a user trying to log in with an invalid user name (a name with spaces in it).
Restarting the server fixes things. There is nothing unusual logged in the murmur.log file.
That's the "silence problem" I was talking about. Here's the tracker for it: http://sourceforge.net/tracker/index.php?func=detail&aid=1816884&group_id=147372&atid=768005
Can you confirm how it's triggered?