Umumur sometimes "looses sound" when someone else connects.

[GoogleCodeExporter]

I'm running umurmur 2.8 on a Synology 411J using a package from 
http://www.nas-forum.com/forum/topic/19052-umurmur-spk-10/
(The huge link in the first post links to packages for the different Synology 
NASs.)

Sometimes it runs perfectly for hours, but usually once every evening we run 
into the problem that other people in the channel can't hear what I'm saying, 
even though the mumble client clearly shows that I'm transmitting. Me 
disconnecting and connecting again fixes the problem.

The NAS has a short sleep time after which it turns off the disks.
Umurmur works fine while the NAS "sleeps", but as soon as a person logs in or 
out, it wants to write to the log or something... because the disks start to 
spin up again.

This "wakeup" seems connected to the problem with loosing sound, since it 
always happens when the NAS spins up the disks.

The spin up of the disks is quite slow, it starts 4 disks one after another, 
and since all of them is in RAID nothing can be written until after they are 
all ready. I'm guessing that it can take as long as 30 seconds to spin up.

I assume that this can also happen to other clients than just me, but I'm 
usually the first one on, and then also the one to "loose voice" when someone 
else logs on.

Another small bug: The log does not contain any newlines or timestamps. This 
makes it rather difficult to actually use it for anything. If possible I would 
rather have a working umurmur than a log of people logging in/out :-)

Original issue reported on code.google.com by timo.din...@gmail.com on 7 Feb 2012 at 2:11

[GoogleCodeExporter]

This behavior originates from the logging to file feature, which was added by 
request from Diaoul who probably is the one who prepared the package for 
Synology that you are using. I was hesitant to add this feature since file 
access typically can result in bad stuff in a single threaded application with 
real-time requirements. 

This problem can't be solved without some major redesign, which won't happen 
anytime soon at least. My best advice is to redirect the logging to /dev/null. 
Just edit umurmur.conf and set

logfile="/dev/null";

If you really need a log you can create a ramdisk, mount it somewhere and put 
the log there.

Original comment by fatbob.s...@gmail.com on 11 Feb 2012 at 10:42

• Changed state: WontFix

[GoogleCodeExporter]

Yes, the version I'm using is in fact the package from Diaoul.

I'll test it out with the dev/null redirect.

I don't need the log for anything. I just wrote about it to tell that it wasn't 
useful for me to provide any information on what was going on when the problem 
occurred. A typical answer when reporting a bug is "Do you have logs, and what 
does it say?"  :-)

Original comment by timo.din...@gmail.com on 12 Feb 2012 at 9:53

[GoogleCodeExporter]

Your bug report really contained all info needed to pinpoint the problem 
without any logs. The info I provided about the options to workaround the 
problem was also if other people encounters the same problem then they can find 
the answer here.

Please leave feedback if the /dev/null redirect works for you. Another option 
is to remove/comment out the line with 'logfile = '.

Original comment by fatbob.s...@gmail.com on 12 Feb 2012 at 10:20

[GoogleCodeExporter]

I've now been using the /dev/null trick for some months, and during that time 
there have been no problems at all.

There is no "spin up" of drives, and no one ever "lost voice" like before.

So this really does seem like a problem with the logging to file.

Original comment by timo.din...@gmail.com on 11 May 2012 at 5:43

[GoogleCodeExporter]

Thanks for the feedback!

Original comment by fatbob.s...@gmail.com on 11 May 2012 at 7:52