similar to: icecast 2 auth problem with (old?) ices, MuSe

-----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, 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: > > > > 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, 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 started to add bandwidth <limit> option to icecast. My ideea is to compute the current bandwidth by estimation on each sock_write*() call. Something like this: 1. initially we set kbps = 0, kbps_time = now and kbps_bytes = 0 2. after some time, a sock_write*() function is called which in turn calls sock_kbps_update(nobytes);

-----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

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 ----

On Tuesday 13 January 2004 03:04, Mihai RUSU wrote: > 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

> > > 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

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

-----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

Hi, I'm using dovecot 1.1.3 on FreeBSD 6.3, x86, files are on NFS, except control and index files, which are local, on UFS2. It's moderately loaded, there are usually not more than 30 clients simultaneously. dovecot runs fine for 3-10 days, then people can't connect any more, and dovecot says: Nov 18 13:20:44 dizzy dovecot-auth: pam_ldap: ldap_simple_bind Can't contact LDAP

> It seems that the official place to grab the source for iproute2 is > http://developer.osdl.org/dev/iproute2/download/ but there are only > sources for 2.2 and 2.6, where are the ones for 2.4? Well I got mine from http://ftp.iasi.roedu.net/mirrors/ftp.inr.ac.ru/ip-routing/ but I didn''t even know about those 2.6 ones... I''m using the latest 2.4.7 with my 2.6.5

I cannot connect MuSe (using line in) to my icecast server. I get thoses messages repeting : Internal buffer inconsistency. flushbits <> ResvSizebit reservoir error: l3_side->main_data_begin: 1640 Resvoir size: 1792 resv drain (post) 5 resv drain (pre) 0 header and sideinfo: 120 data bits: 679 total bits: 804

Pardo Juan Fernando wrote: > Somebody can answer me wich stream is better...Liveice or Muse ? > > --- >8 ---- > List archives: http://www.xiph.org/archives/ > icecast project homepage: http://www.icecast.org/ > To unsubscribe from this list, send a message to 'icecast-request@xiph.org' > containing only the word 'unsubscribe' in the body. No subject is

What''s wrong... I have Celeron 633MHz nd 768Mb RAM. When I''m running my script everything is OK, but when I''m connecting Internet and LAN link computer is hanging. But when i dissconnect this everything is OK. I have 500 users, 1500 classes and 3000 filters. Is it normal? What should I do?