search for: thread_mutex_lock

...read_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); > < thread_mutex_lock (&info.source_mutex); > 694c687 > < if (sourcecon) > > if ((sourcecon = relay_pull_stream (req, &...

...o this: xa_debug (1, "DEBUG: Trying transparent proxy with host: [%s]", req->host); 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); thread_mutex_lock (&info.source_mutex); if (sourcecon) Simple enough... yes? But is it correct. It seems to work in my test cases. If anyone still follows 1.3.12, please add your input. Finally,...

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

...is this feature implemented 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 loc...

...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); < thread_mutex_lock (&info.source_mutex); 694c687 < if (sourcecon) --- > if ((sourcecon = relay_pull_stream (req, &err))) Enjoy --...

> to wait when called. I commented out the line where it calls > thread_mutex_lock and it all seems to work now. Ick. What a hack :) It does seem to be a deadlock issue. But I wouldn't recommend anyone trust just removing that. Locks are there for a reason :) jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecas...

...oid *param) { + stdinpcm_state *s = mod->internal; + switch(ev) { case EVENT_SHUTDOWN: @@ -50,6 +67,20 @@ case EVENT_NEXTTRACK: ((stdinpcm_state *)mod->internal)->newtrack = 1; break; + case EVENT_METADATAUPDATE: + thread_mutex_lock(&s->metadatalock); + if(s->metadata) + { + char **md = s->metadata; + while(*md) + free(*md++); + free(s->metadata); + } + + s->metadata = (char **)param; + s-&g...

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

On Sat, 2004-01-17 at 19:31, iceuse@kezako.net wrote: > Thanks, > Karl, do you plan to integrate this in your icecast-kh release? The idea is to put the the changes I've done into CVS. That way you get the best of both worlds, there's nothing conflicting AFAIK. karl. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage:

...rce_find_mount (source->fallback_mount); avl_tree_unlock (global.source_tree); if (fallback_source) { INFO2 ("passing %d listeners to %s", fallback_source->mount,source->listeners ); /* Do we need to lock the current source? */ thread_mutex_lock (&fallback_source->lock); source_move_clients (fallback_source, source); thread_mutex_unlock (&fallback_source->lock); } } ) (this code is added in source.c:source_init) Regards, Chris --- >8 ---- List archives: http://www.xiph.org/archives/...

Hi, I urgently need a feature to save the dump-files in splitted timestamped chunks or - much better - named accordingly to the stream metadata. I don?t want to use utilities like streamripper to make dumps because they act as a client and thus the "relay on-demand" feature of icecast isn't usable anymore. I only want to have a copy of the stream when somebody is actually

On Friday 20 February 2004 12:10, Ricardo Galli wrote: > > wants to send such a patch, we're happy to integrate them. I don't > > remember the DoS bug - that might be a real problem. It could be that a > > It started out with this: > > http://www.xiph.org/archives/icecast-dev/0366.html > > and I found the problem and sent the patch: > >

Hello, I work at SmarctJog.com, we have here some patches on IceCast for performance and reliability, these are mostly client/connection/source cleanups (a slave merge is underway, and some more good stuff (c)), but we'd like this to be merged in before the list gets any longer. Please find attached a list of our patches with a short desc: This one is actually not from us/me, it was found