similar to: ICE/1.0 specs

Jack Moffitt wrote: > Why are you writing clients that don't use libshout? <p>darkice doesn't use libshout either. I guess the main reason to have a protocol is that anyone can connect using it? <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to

On Friday, 08 February 2002 at 13:12, Samuel Hathaway wrote: > On Fri, 8 Feb 2002, Akos Maroy wrote: > > > Jack Moffitt wrote: > > > > > Why are you writing clients that don't use libshout? > > > > darkice doesn't use libshout either. > > > > I guess the main reason to have a protocol is that anyone can connect > > using it? >

On Thu, 7 Feb 2002 10:29:29 -0700, Jack Moffitt wrote: >> I'm looking for specifications of the ICE/1.0 protocol. Not everything >> could be derived from the source code of the icecast 2.0 server. > >It's not all there or documented because it's still a work in progress. >Specifically the source login part is going to be significantly changed. > >Why are you

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 the download page for icecast, I can read in the icecast-2.2.0 changelog that there's support for AAC: AAC is added as a supported streaming format Not too many source clients support streaming in this format, but we support it. but when looking at the source code for icecast-2.2.0, I can't find reference to AAC anywhere. in particular, in format.c the format_get_type function only

well, don't get me wrong, I am not generally opposed to progress, but speaking as a coder of source clients, providing yet another authentication mechanism is a bit frustrating.... I guess it wasn't too bad having to deal with Shoutcast/Icecast/Icecast2 specific connection protocols (yes they are ALL different!) but I am NOT going to support Shoutcast/ICecast/Icecast2 (ICE

On Fri, 8 Feb 2002, Brendan Cully wrote: > On Friday, 08 February 2002 at 13:12, Samuel Hathaway wrote: > > On Fri, 8 Feb 2002, Akos Maroy wrote: > > > > > Jack Moffitt wrote: > > > > > > > Why are you writing clients that don't use libshout? > > > > > > darkice doesn't use libshout either. > > > > > > I

on 2/6/02 10:19 AM, Jack Moffitt at jack@xiph.org wrote: >> It's not my bandwidth from the server... a week ago, I was streaming >> Shoutcast from Windows with no problems. It's not my bandwidth at work >> (where I'm listening), I can pull in other 128k streams with no problem. >> >> Help? > > Where is shout? > > And you shouldn't be

On Wed, 6 Feb 2002, Jack Moffitt wrote: > ices is built on libshout. libshout should have perfect timing and it > also detects and discards corrupt frames and supports VBR streams. It > is basically the _new_ version of shout. ices refuses to load. It whines about libmp3lame.so.0 being missing. I found the message in the archives that supposedly forces ices to compile with lame

Hi, I just updated my CVS copy of icecast2, and saw that the default login protocol now is HTTP basic authentication, which ICE/1.0 still selectable through the config file (by inserting an <icelogin>1</icelogin> element). My question is: what is the intended future login protocol for icecast2? Will ICE/1.0 be phased out in favour of HTTP basic auth? <p>Akos --- >8

On Thu, Jul 17, 2003 at 09:55:04AM -0600, Jack Moffitt wrote: > Please speak to Ralph Giles <giles@xiph.org> about obtaining commit > access to CVS. We should check in your debian/ dir into the official > tree and that way we can be sure to sync releases. Also people using CVS > snapshots will be able to build their own debs. Well... Thanks! I've been maintaining my own

> Done, and it's working... but not significantly better than before. > Whereas before I couldn't clear a single song without the stream devolving > into skipping, now I'm averaging between 15-20 minutes. Better, but still > not acceptable. THen I suggest you start to look elsewhere for your problem. libshout is quite well tested and every time someone has thought it was

See below... > From: Jack Moffitt <jack@xiph.org> > Reply-To: icecast@xiph.org > Date: Mon, 27 Aug 2001 10:27:06 -0600 > To: icecast@xiph.org > Subject: Re: [icecast] Icecast Problems Get Worse > > Hunter, > > You can look in ices/src/libshout/configure.in at the top I think. libshout 1.0.6 > > Icecast doesn't have SMP issues that I know of, as we

I'm using whatever comes with Icecast 1.3.11 and Ices 0.22. Just grabbed both tarballs from Icecast.org. Is there a way to find out the libshout version? I can't really tell from the Ices source... Hunter > From: tim <tim@nvhs.nl> > Reply-To: icecast@xiph.org > Date: Mon, 27 Aug 2001 17:57:07 +0200 > To: icecast@xiph.org > Subject: Re: [icecast] Icecast Problems

> Yeah I did. but just to be sure, I did another update on everything, > rebuilt libshout, installed it in /usr2/friends/geoff, checked the date > stamps on the lib and the header to make sure they actually installed, > reconfigured ices and tried make again. The stream.c errors persist. > look further? I'm almost 100% certain CVS code has the right fixes. Paste an instance

Has anyone looked at added Speex support to icecast2 and ices? I'm not quite sure where to start adding support and don't want to duplicate it if someone else has. --Joe -- Joe Sunday <sunday@csh.rit.edu> http://www.csh.rit.edu/~sunday/ Computer Science House, Rochester Inst. Of Technology --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage:

I changed the libshout2 and thread module apis. This broke everything. If you are tracking CVS, make sure to update your libshout2 and the thread module. Ices2 and Icecast2 already uses these new changes, which were implemented as part of general cleanup and getting Solaris builds out of clean tarballs. If anyone is having build issues now, on linux or solaris, please let me know. jack. ---

A question to icecast2 developers: is there a possibility to have some sort of user feedback in icecast2? I'm thinking of having a client that would send some info back though the same socket it receives the stream. If no such feature currently exist, where should I start to implement it? Thanks, <p>Akos <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast

When compiling ices-2.0, I got the following error: In file included from config.h:4, from input.c:15: stream.h:16:25: shout/shout.h: No such file or directory Has anyone encountered this problem before? It appears that these headers are missing...does anyone know where they may be located? Any insight is much appreciated. dap -- -- D. Anthony Patrick [

The ice-* headers are the standard protocol for connecting to icecast2, the trouble is making all source clients adhere to the standard. The option is to be very militant about it, and basically deny any source clients that do not connect with the ice-* headers , but we chose the more compatable route...although there is a limit to this compatability....I would strongly urge darkice to use