similar to: Why doesn't yp.icecast.org show my stream?

Dave Hayes <dave@jetcafe.org> writes: > Darkice has: > public = yes > So I check darkice: > Icecast.cpp: > ... > str = "\nx-audiocast-public: "; > sink->write( str, strlen( str)); > str = getIsPublic() ? "yes" : "no"; > sink->write( str, strlen( str)); > and then icecast: > .... > else if

Just following up to myself here so this will be in the archive for people. The problem was in darkice 0.7. There is a patch required to make it comply with the x-audiocast-public "standard". You can get the latest CVS to fix the problem. ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<<

[Reposted here, silence on the icecast list, is this deliberate?] Once again, I'm clueless as to what is going on because I don't have the source or logs to yp.icecast.org. I am touching yp.icecast.org fine: [14/Feb/2002:01:39:22] directory_touch_xa([yp.icecast.org:80]) completed...server id = 69 but my radio station isn't shown. More details on my setup: xmms -> darkice

Jack Moffitt <jack@xiph.org> writes: > Now I see the problem. This will not cause anything to show up. You > have no sources. Eh? -> sources Listing sources [Id: 509] [Sock: 14] [Time of connect: 18/Feb/2002:20:55:14] [IP: 205.147.43.110] [State: 1] [Type: pulling relay] [Proto: x-audiocast] [Clients: 2] [Dumpfile/fd: (null)/-1] [Priority: 0] [Song Title: ] [Song URL:

Once again, I'm clueless as to what is going on because I don't have the source or logs to yp.icecast.org. I am touching yp.icecast.org fine: [14/Feb/2002:01:39:22] directory_touch_xa([yp.icecast.org:80]) completed...server id = 69 but my radio station isn't shown. More details on my setup: xmms -> darkice 0.7 -> relay icecast server -> main icecast server

telmnstr <Ethan> writes: > We have been using LiveIce to serve mp3 streams for 10 months or > so. ... > Does anyone have suggestions? By leaving LAME and trying to go with L3ENC > or whatever the current version is -- will that improve stability? One more for Darkice here. My experiences with LiveIce were less than fruitful. I used to use the shoutcast plugin on windows but,

Jack Moffitt <jack@xiph.org> writes: > What are you trying to do that you get that error? I sent an improperly formatted URL to your server. I've corrected this since. =) > id=69 is the normal success code. You'd get -1 if it failed I think. > What's your ip address? I'll go check the logs. The ip address of my streaming server is 216.133.255.2 > Other

On 24/02/02 05:02, Jack Moffitt shaped the electrons to say: > > - The server didn't check for the status of the client's socket before > > the unblocking send(). This caused a disconnection at a minimun network > > congestion, causing a broken pipe error (Linux 2.4 behaviour?) in the > > network. I've just added a poll in sock.c.> > Can you send me this

Jack Moffitt <jack@xiph.org> writes: > The source is in icecast cvs in the 'icedir' module. But what's > actually running is slightly modified. $ setenv CVSROOT :pserver:anoncvs@xiph.org:/usr/local/cvsroot $ cvs login ... $ cvs -z 1 co icedir cvs server: cannot find module `icedir' - ignored cvs [checkout aborted]: cannot expand modules It's not there or I've

Jack Moffitt <jack@xiph.org> writes: > The source is in icecast cvs in the 'icedir' module. But what's > actually running is slightly modified. Heh. Is it possible to see a copy of what is actually running? I'm probing the directory server with a quick script but I'm getting 400 URL must be absolute which I should figure out soon. >>

On 19/02/02 06:14, Jack Moffitt shaped the electrons to say: > > well, at 128kbps bitrate, it's only 6 seconds of data. 30 seconds would > > have been more reasonable, how does everybody think? it might have to be > > varied based on the bitrate of the stream. > > Good point. I will make this configurable in the end. 6 seconds is too > little. I'll see what I

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

yes this is darkice. perhaps we could work in 'icy-public' support...? --mark On Tuesday, Jul 8, 2003, at 19:58 US/Pacific, Arc wrote: > On Tue, Jul 08, 2003 at 03:40:42PM -0500, oddsock wrote: >> what source client is generating that ? > > I believe they run darkice, Mark Burdett would have to supply more > specific details as this is a relay of their lofi-mp3

On 19/02/02 18:09, Likai Liu shaped the electrons to say: > >It's partially done in the patch I've sent you, completelly done in my > >current version... I can send you the second patch, you will save some > > work. > > how is the calculation being done? do you extract the bitrate from the > stream data, or do you use a different method? I'd advocate *that*

Mike hodson <mystica@darktech.org> writes: > Might I ask -how- precisely they banned all icecast servers. Perhaps the real question you should ask is..."should" anyone worry about this at all? Personally speaking, I've been streaming for quite a while (barring a few networking problems) and I've always seen the same behavior from the shoutcast (Nullsoft) people.

Hi again, most probably this patch won't be applied either, nevertheless, I inform the problems and my own modifications.... Included in the patch (just touches sock.c and sock.h): - Due to the semantics of the close() function, the server hangs on close() if a client just dies (the machine just "dissapear" from the network) and there is still data to send in the TCP

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

Hi all, I am ricardo galli, I've juscribed just a couple of days ago. I wanted to stay as a lurker for a longer period, but this list has almost no traffic, so I wake up due to the silence. The point is, is this list related to icecast2 development? I made some changes to the server and sent a patch to Jack Moffitt, but I'm not sure he's still mainaining the server. If he

In trying to find out why neither icecast nor shoutcast no longer lists my radio station (I thought it might be the connectivity issues which plagued me this month), I find this: >> unfortunately, the kind folks over at Nullsoft axed all icecast entries on >> their YP... >> Quote from Tom Pepper : >> >> "I also had to pull support for icecast today from the

I send a patch again the last CVS version. The changes are: - Configurable prebuffer, in seconds. - prebuffering parameter in configurable in <limits>...<prebuffer>seconds</prebuffer>... - Created a new function (send_client_queue) to send the client->queue. Better modularisation. - Moved queue_lenght verification to send_client_queue(). - instead of disconnecting when