similar to: [PATCH] IceCast2 - aliasing (reimplementation of the patch I posted earlier)

I wrote a patch which makes client connections retain info about which socket they connected to - this way, you can change the server's behavior based on which <listen-socket> is being connected to. In addition, I added a field to the <listen-socket> section of the config file called <default-mount> which specifies a default file in the case that one isn't specified (it

----- Original Message ----- From: "Michael Smith" <msmith@xiph.org> To: <icecast-dev@xiph.org> Sent: Wednesday, June 04, 2003 3:47 PM Subject: Re: [icecast-dev] libshout2 compiling problems under FreeBSD? <p>> Whilst there may well be problems, there are no _known_ problems, and we > certainly won't be able to fix them unless you actually tell us what the

Hi, A radio is being developped at school, and we wanted to avoid eating too much bandwidth, so we had a look at RTP. I first implemented it in icecast1 and it worked well (although we had to apply a patch to make RTP work with xmms). We are indeed saving a lot of bandwidth. I then adapted it to icecast2, here is the patch. The biggest trouble for now is the configurability. I added 3 global

Hi, You don't check for malloc failure. I've made a patch that is possibly wrong but it saves the program from SIGSEGV and replaces it with SIGABRT. -peter diff -ru icecast-2.3.2-ORIG/src/admin.c icecast-2.3.2/src/admin.c --- icecast-2.3.2-ORIG/src/admin.c Fri May 2 17:40:00 2008 +++ icecast-2.3.2/src/admin.c Thu Apr 28 19:53:03 2011 @@ -291,6 +291,9 @@

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

Hi, We're having some problems with streamed metadata and I thought I'd see if upgrading Icecast would fix it. This box is running rather old software including Icecast 2.2.0 and I wasn't planning on upgrading it, but I think this is a good reason to try. I also have it built in a non-standard place so this may be a build issue. due to older versions of automake etc, I got the

Hello, Last night there appears to have been a loop in the network of my colocation provider. Somehow this loop/packet flood caused tinc to crash. I guess that, even though it seems to have restarted, it did not manage to reconnect/re-open the tap device/something else went wrong; the machine itself was communicating with the internet but I could not access it over the VPN. The most

Well, I can't get icecast to compile on IRIX, not a huge surprise to me, but i'm working on it: First problems, the configure script doesn't work well with IRIX in general, so a bit of manual changes to it were required to force some library locations and compiler flags for the ogg and vorbis tests. (Mainly, $PREFIX/lib is not a safe assumption, as there are $PREFIX/lib,

I am still having this weird problem with nodes hanging while I'm running OCFS. I'm using OCFS 1.0.9-12 and RHAS 2.1 I've been working on tracking it down and here's what I've got so far: 1. I create a file from node 0. This succeeds; I can /bin/cat the file, append, edit, or whatever. 2. From node 1, I do an operation that accesses the DirNode (e.g. /bin/ls) 3. Node 0

I am still having this weird problem with nodes hanging while I'm running OCFS. I'm using OCFS 1.0.9-12 and RHAS 2.1 I've been working on tracking it down and here's what I've got so far: 1. I create a file from node 0. This succeeds; I can /bin/cat the file, append, edit, or whatever. 2. From node 1, I do an operation that accesses the DirNode (e.g. /bin/ls) 3. Node 0

Geoff Shang wrote: > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I./.. -pthread -g -O2 -c sock.c > -Wp,-MD,.deps/libicenet_la-sock.TPlo -fPIC -DPIC -o > .libs/libicenet_la-sock.o > sock.c: In function `sock_get_server_socket': > sock.c:702: `IPV6_V6ONLY' undeclared (first use in this function) > sock.c:702: (Each undeclared identifier is reported only once > sock.c:702:

Hi, I couldn't find anything about this subject from archive - are there known problems with compiling libshout2 under FreeBSD 5.1 or 4.8 (both are up to date). I downloaded libshout2 latest nightly snapshot and tried to compile it on 5.0 and then later on 4.8. Both failed (problems were mostly around sock.c, sock.h, resolver.c - redeclaring and syntax errors). Thinking that it might be a

On Wednesday 06 October 2004 09:32, Geoff Shang wrote: > Hi: > > I maintain an Icecast server at acbradio.org. Recently it's been crashing > fairly regularly. I've not yet upgraded it to 2.0.2. I thought I'd report > this crash bug first as the release note seemed to suggest that the fix > there was only for Windows. I'm thinking that either this is a separate

Hi: I maintain an Icecast server at acbradio.org. Recently it's been crashing fairly regularly. I've not yet upgraded it to 2.0.2. I thought I'd report this crash bug first as the release note seemed to suggest that the fix there was only for Windows. I'm thinking that either this is a separate problem or it's an example of the same one under LInux, thereby making it

hem here it is the patch. ;) bye kysucix -------------- next part -------------- Index: conf/icecast.xml.in =================================================================== --- conf/icecast.xml.in (revisione 10365) +++ conf/icecast.xml.in (copia locale) @@ -62,6 +62,7 @@ <port>8001</port> </listen-socket> --> +

Thanks for the info. I checked the config.log and I got this information. configure:9311: checking for xsltParseStylesheetFile configure:9361: gcc -o conftest -O20 -fsigned-char -D_REENTRANT -I/usr/local/inc lude -I/usr/local/include/libxml conftest.c -lpthread -L/usr/local/lib -lxsl t -lxml2 -lz -liconv -lm >&5 ld: -lpthread: no match collect2: ld returned 1 exit status It seems

Hi, One one server running tinc we're seeing a lot of syslog messages like the following: Old connection_t for XXXXX (xxx.xxx.xxx.xxx port 655) status 0014 still lingering, deleting... The last time these messages appeared, they referred to 2 of the 3 remote ends that this server is connected to. They appear regularly, once every minute. The VPN still works fine, but I have to restart tinc

On Mon, Nov 18, 2019 at 11:53:39PM +0200, Nir Soffer wrote: >This series extract oVirt SDK and imageio code to make it eaiser to follow the >code and improve error handing in open() and close(). > >Tested with virt-v2v master. > >Changes since v1: >- Rebase on merged patches from v1 >- Fix regression introduced by "rhv-upload: Fix cleanup after errors" >-

i ran into the same issue yesterday. i had to revert back to 1.6 here is the link to the exact file that helped me ftp://ftp.gnu.org/gnu/automake/automake-1.6.tar.gz then tar -zxf automake-1.6.tar.gz; cd automake-1.6l; ./configure; make; make install <p><p>Dave St John CEO Mediacast1 www.mediacast1.com ----- Original Message ----- From: "Tano M Fotang"

On Tue, Nov 19, 2019 at 01:14:23PM +0200, Nir Soffer wrote: >On Tue, Nov 19, 2019 at 11:17 AM Martin Kletzander <mkletzan@redhat.com> wrote: >> >> On Mon, Nov 18, 2019 at 11:53:39PM +0200, Nir Soffer wrote: >> >This series extract oVirt SDK and imageio code to make it eaiser to follow the >> >code and improve error handing in open() and close(). >> >