search for: source_mutex

...th mutexes being locked multiple times with the same thread; which is where the problem may be; In find_mount_with_req() (which must be called with mutex's locked) if the transparent proxy is set, it calls relay_pull_stream(), (line 687) which eventually calls source_login which relocks info.source_mutex. (This was Alex's find) At this point, that thread is locked up, and eventually the second connection handler thread tries to lock it, and the calendar thread too. The original server is unable to send data so it kicks the relay and the server is hosed. The potential fix for this is c...

...diff fixes problems with 1.3.12. > > [wolpert@memeplex] src> diff icecast-1.3.12/src/source.c > old/icecast-1.3.12/src/source.c > 686,692d685 > < thread_mutex_unlock (&info.mount_mutex); > < thread_mutex_unlock (&info.source_mutex); > < thread_mutex_unlock (&info.double_mutex); > < sourcecon = relay_pull_stream (req, &err); > < thread_mutex_lock (&info.double_mutex); > < thread_mutex_lock (&info.mount_mutex);...

Hi, The only need I have for icecast is as a transparent proxy. The problem is I can't get it to work as one, is this feature implemented? When I setup XMMS with a proxy of the computer running icecast (1.3.11) I get this in the logs when trying to connect to a stream: [16/Sep/2001:23:59:31] [9:Connection Handler] Accepted encoder on mountpoint 205.188.234.34:8004/ from

...I fixed the problem, it seemed that in source.c in the function source_login in this piece of code: -- write_log (LOG_DEFAULT, "Accepted encoder on mountpoint %s from %s. %d sources connected", source->audiocast.mount, con_host (con), info.num_sources); thread_mutex_lock(&info.source_mutex); avl_insert(info.sources, con); thread_mutex_unlock(&info.source_mutex); -- I found that the code was stopping after the thread_mutex_lock, my guess (seeing as it's 2am in the morning and I'm just happy to have it working) is that the mutex has already been locked causing this functi...

...he same boat, the following diff fixes problems with 1.3.12. [wolpert at memeplex] src> diff icecast-1.3.12/src/source.c old/icecast-1.3.12/src/source.c 686,692d685 < thread_mutex_unlock (&info.mount_mutex); < thread_mutex_unlock (&info.source_mutex); < thread_mutex_unlock (&info.double_mutex); < sourcecon = relay_pull_stream (req, &err); < thread_mutex_lock (&info.double_mutex); < thread_mutex_lock (&info.mount_mutex); <...

...erating system is Red Hat Linux 8.0. Under these circumstances and after variable periods of time our icecast server hangs. At present we suppose that it is the call of "close_connection" at the end of function "source_func" that locks the "double_mutex" and the "source_mutex" and causes this problem. Maybe there is a problem with the big number of source streams? For hints on known bugs or any ideas we would be thankful. Alexander Daxenberger -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail...

Hi Karl, Thanks for your help, About the "Connection:" header, you are right, it's: "Connection: close" and NOT "Connection: keep-alive". The protocol when the SERVER sends the data is http 1.0. It's http 1.1 when the browser requests the data. I don't understand the "Content-Length: 54000000" header either. Also I noticed the flash player on