similar to: Possible Minor bug found in current 2.3.1 release of icecast2

Genuis karl! The change sorted it. Now when the source disconnects, the winamp stream just stopped (and went onto the next stream in the playlist in my case) Cheers for your help, Oddsock, could you build a compiled windows version of icecast with this fix (and also the relay on demand default setting as enabled, also fixed by karl) Whenever you have a spare moment, it would make me very very

I'm trying to get icecast 2.3.1 compiled on a slackware 10.0 box. I've successfully compiled the libshout libraries. Now this is what I got after a make in the source dir: > make[3]: Entering directory `/tar_archive/icecast-2.3.1/src' > /bin/sh ../libtool --mode=link gcc -pthread -g -O2 -L/usr/local/lib > -o icecast cfgfile.o main.o logging.o sighandler.o connection.o

Here is a patch for icecast 2.3.2 that adds support for listening to mp3 and aac+ streams on the iphone. A quick background on the technical aspects of the patch and why it is needed : With the advent of 3g on the iphone, lots of people have been jumping on the bandwagon of providing internet radio streams that work on the iPhone. The biggest problem is that (without having to install an

On Saturday 18 January 2003 16:04, Michael Smith shaped the electrons to shout: > On Sunday 19 January 2003 01:59, Ricardo Galli wrote: > > On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons > > to > > > > shout: > > > We can't just drop packets, the transmission model assumed by the > > > format handlers (and required by at

On Sunday 19 January 2003 03:35, Michael Smith shaped the electrons to shout: > There's a bad interaction here between the predata and this faststart. > Suppose we have two logical streams (A and B), and the stream has just > recently got to logical stream B. Now, this means the fast start queue > contains the end of stream A, then the stream B headers, then the start > of

On Sun, 25 Apr 2004, Wild Karl-Heinz wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x08057f50 in format_mp3_write_buf_to_client (self=0x80bee00, client=0x80d5e00) > at format_mp3.c:311 > 311 if (ret < (int)refbuf->associated->len) > > what else can i do? When you get to this point, you should do a backtrace so Karl can see what is

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, find enclosed a patch to implement faststart (or prebuffering). Basically, it stores a number of "refbuf"s, configurable by seconds. When a new client connects, it adds the prebuffers to que clients' queue so they are delivered as fast as permitted by the connection. As result, the players prebuffers are filled up faster giving a better "response". I tried

Ok here's the deal. I set up Icecast and Oddcast, got them to communicate properly, but cannot access the live audio remotely. On other computers in the LAN it works perfetly. Currently I operate wirelessly behind a D-Link 514 router (a mite outdated by now, yes?) and have opened all necessary ports, turned my firewalls off, set this computer as a DMZ, pretty much everything I can think of -

Hello, I'm a new user of icecast which is a really cool software. I use it with the the http proxy module of apache httpd to do port forwarding with 2 sub domains. On my router i forward all tcp traffic of the port 80 to my server. 2 Sub domains are redirected to my server : radio.mydomain.com (icecast) music.mydomain.com (ampache) my apache server host the ampache application with a

On 19/02/02 23:09, Likai Liu shaped the electrons to say: > Ricardo Galli wrote: > >By assigning a timestamp to each packet read from the source socket. I > > think the only sane way to do it. > > great idea. with this implementation, actually you can set a smaller > buffer size, but wait a longer time for recovery. once congestion is > clear, previous "missed"

marco chrappan wrote: > I'm trying to get icecast 2.3.1 compiled on a slackware 10.0 box. I've > successfully compiled the libshout libraries. Now this is what I got > after a make > in the source dir: > > >> make[3]: Entering directory `/tar_archive/icecast-2.3.1/src' >> /bin/sh ../libtool --mode=link gcc -pthread -g -O2 -L/usr/local/lib >> -o

Hi, I'm trying to adapt darkice to the current state of icecast2. As I see, there is a possibility to stream in various formats, by specifying a Content-type field on the source header. When I try to log in with an mp3 source, I get a seg fault from icecast2. The connection looks something like: SOURCE /mountpoint ICE/1.0 Content-type: audio/mpeg ice-password: password ice-bitrate: 96

On 05/08/2011 01:06 AM, Romain Beauxis wrote: > Running out of memory is not considered as an error when calling malloc? On linux, the only way to get an error when calling malloc() is to disable memory-overcommiting. On regular linux systems, this is the _only_ way for malloc() to return NULL. If an icecast process reaches that point, it's screwed anyway it won't be able to do

Hi, If you have multiple players installed on your PC/Mac .m3u will always open the last media player who are the default in charge of the extension and mime m3u. On your web site you want maybe to force a link to open real media player or quicktime/itune. You need to create a .pls to force winamp loading the streaming because windows media player won't open .pls etc. If you add a .pls

latest kh build is here : http://www.oddsock.org/icecast/icecast2_win32_kh_trunk_07292005_setup.exe oddsock At 04:56 AM 7/29/2005, Ricardo Meechan wrote: >Genuis karl! The change sorted it. >Now when the source disconnects, the winamp stream just stopped (and >went onto the next stream in the playlist in my case) > >Cheers for your help, > > >Oddsock, >could you build

I finally managed to get back to working on this patch. To get some feedback I've linked to it and posted a few comments on it. http://mediacast1.com/~karl/single-q.diff My previous patch (client write) I sent to the list needs to be applied first, there was no feedback to it. http://www.xiph.org/archives/icecast-dev/1153.html (looks like it still applies to svn, if not then let me know)

Hi, I'm trying to build Icecast on a RedHat AS3 workstation. All the requisite libraries are already bundled with the distro. IThe compile runs for maybe 30 seconds (maybe less) and then fails. The last few lines of the make output are appended below. I'm not even sure what it's actually complaing about. gcc -pthread -g -O2 -o icecast cfgfile.o main.o logging.o sighandler.o

This small example will make icecast unusable after few seconds. The problem resides on EPIPE received when trying to send the first (58) bytes of the vorbis predata. Change the URL for your own, and try it in a LAN. I have no idea on the reasons of these errors, altough I suspect it's related to the fact that the headers are sent in blocking state and then we change to non-blocking. I

I'm getting strange behavior with this build. My relays do not work. If I change back to the build on 7/13/05, everything works. However with the new build I get this error message: "[2005-08-01 10:06:16] EROR format-mp3/format_mp3.c Incorrect metadata format, ending stream" Any ideas why? Fred -----Original Message----- From: icecast-bounces@xiph.org