similar to: net/sock.c question

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 13 Feb 2004, Dave St John wrote: > > > > Another nice feature to add would be a "bandwidth" limit (so just a > new > > > > <limit> type entry). > If you are running icecast2 on linux you can handle bandwidth limitations > using QoS > more specificly iproute2. You mistunderstood me. No, I

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 13 Feb 2004, Geoff Shang wrote: > Mihai RUSU wrote: > > > Another nice feature to add would be a "bandwidth" limit (so just a new > > <limit> type entry). > > Problem with this is, what do you do once the limit has been reached? Who > do you kick? Or do you just not allow anymore listeners? I

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 13 Feb 2004, Dave St John wrote: > I think that would be a good feature to add in icecast2, dont get me wrong, > im just saying with QoS > you have far much more flexibility in handling bandwidth. > tcp/ip packets can be marked with iptables and then ran threw tc which you > could then prioritize your packets You mean by using

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi In connection.c arround line 847 icecast2 does: if (global.clients >= client_limit) { client_send_504(client, "The server is already full. Try again later."); global_unlock(); return; } Then just a little bit later, does the same thing in the if (source) {} block. Is this code

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I will need to find a solution for server side limit of clients bandwidth depending on their IPs (because we have very fast local connections with local ISPs and slow "external" connections with the rest of the Internet). Initially I think I'll just start 2 icecast servers (one for "local" clients, one for

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I have recently downloaded icecast 2 (I am an old icecast 1.x user) and tried to use it with my ices 0.2.3 (which works on icecast 1) but fails on login. Also I have tried with MuSe 0.8.1 and same error too. After some digging into the sources I found the problem to be with _check_pass_icy() which receives a "strange" pass to compare

I think that would be a good feature to add in icecast2, dont get me wrong, im just saying with QoS you have far much more flexibility in handling bandwidth. tcp/ip packets can be marked with iptables and then ran threw tc which you could then prioritize your packets set a limit and a burst for variable bitrates. (http://svana.org/kleptog/Packet-Shaping-HOWTO.txt) I know there isnt any "drop

Okay, I am using libshout to stream to a NullSoft Shoutcast server. I am using libmad and libmp3lame to do re-encoding on the fly. I am streaming to the server (currently) with shout_send_raw(). When I try to use shout_metadata_add(), I get a segfault in strdup(). Anyone have any ideas as to why? Everything else works fine, just not the metadata. Thanks In Advance, Deven --- >8 ----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Huh, why not just use ices with a perl song choser module ? This eliminates the need to develop the libshout based streamer (use ices instead) and give ices the title from your module, ices will take care of the rest. Or I am wrong ? :) On Wed, 25 Feb 2004, Renaud Waldura wrote: > For what's it's worth, I do something similar to this

> > > Another nice feature to add would be a "bandwidth" limit (so just a new > > > <limit> type entry). If you are running icecast2 on linux you can handle bandwidth limitations using QoS more specificly iproute2. That way icecast2 doesnt have to take up extra resources to handle bandwidth limitations. resources here cbq bash script

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael and thanks for answer! On Tue, 13 Jan 2004, Michael Smith wrote: > This shouldn't be being passed to _check_pass_icy() at all - this isn't the > "icy" (shoutcast nasty ugly) protocol at all. We support that (icy) protocol > because it's widely used - but it's a horribly ugly hack to pretend that

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 16 Jan 2004, Deven Phillips wrote: > Okay, > > I am using libshout to stream to a NullSoft Shoutcast server. I am > using libmad and libmp3lame to do re-encoding on the fly. I am streaming > to the server (currently) with shout_send_raw(). When I try to use > shout_metadata_add(), I get a segfault in strdup(). Anyone have

Mihai, Here's the full backtrace. (gdb) bt full #0 0x40292093 in strlen () from /lib/i686/libc.so.6 No symbol table info available. #1 0x40291dc5 in strdup () from /lib/i686/libc.so.6 No symbol table info available. #2 0x400aed79 in _shout_util_dict_set (dict=0x0, key=0x804b746 "song", val=0x0) at util.c:236 prev = (util_dict *) 0x80555b8 #3 0x400ad61b in

I must use Windows for Streaming. and the interface must be an port or something else, because the software interface runs on a dedicated server. ----- Original Message ----- From: "Ricardo Galli" <gallir@uib.es> To: <icecast-dev@xiph.org> Sent: Wednesday, February 25, 2004 10:10 AM Subject: Re: [icecast-dev] I need a Freelance Coder... <p>> On Wednesday 25 February

Hello, I've created a macromedia flash player in order to play icecast mp3 streaming. Icecast is configued on the port 8000 and It's ok with winamp. In my flash movie, I've used loadSound("<streaming>",true) on a Sound object. It's ok on Mozilla based browsers but some user don't have sound on Internet Explorer. D't understand? Is there an issue? Thx

On Mon, 2005-06-27 at 19:33, Michael Kamleitner wrote: > hi, > > icecast 2.2.0 has to be patched slightly to work with flash-players using > the sound-object - cant find the exact link to this, maybe one of the > developers can explain? I just added 4 lines at the end of > format_mp3_send_headers() in format_mp3.c: > > sock_write(client->con->sock,

I've attached a small patch against icecast 2 which converts ice- headers to icy- headers for clients that include icy- headers in their request. This allows a few clients (notably xmms) to pick up stream info they otherwise miss. -b -------------- next part -------------- Index: src/format.c =================================================================== RCS file:

I though I should let you all know of this: Trying to build R-0.62.2 on a SunOS xxxx 4.1.4 2 sun4m machine using gcc (gcc version egcs-2.91.57 19980901 (egcs-1.1 release)): gnumake[2]: Entering directory `/tmp_mnt/xxxx/src/R-0.64.2/src/unix' gcc -g -O2 -I../include -I../../src/include -c Rsock.c -o Rsock.o In file included from Rsock.c:8: sock.h:21: parse error before `Sock_read'

Is there any flash based players out that can be embedded into a webpage and stream a icecast feed? -=-=-=-=-=-=-=Ottawa Valley Weather-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Weather @ 5:50pm - Temp: 31.1?C - Humidity 23% - Wind: W @ 0 km/h Baro: 1001kPa Falling - Vis: 24km - Sky: Few Clouds - Weather: --- Hourly Rain: 0.00mm - Daily Rain: 0.00mm - Total Rain(May 28th): 1.00mm =-=-=-=

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