similar to: icecast2 seg fault

> 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. All the hooks are there for other formats, but we haven't added any but Vorbis. > When I try to log in with an mp3 source, I get a seg fault from > icecast2. The connection looks

Hi, A question for the HTTP Basic auth for icecast2: what is the username to use when doing such authentication. The related line in the login is: Authorization: Basic <base64 encoded string> where the <base64 encoded string> in its original form is: username:password now, what username is used? in the config file for the icecast2 server, one can only set the password (except

I am new to your lists but I have found something in icecast 2.3.1 that may need further review. there is a segfault when you have a failover mount point and the failover mount is using ezstream and you restart ices-2.x and the clients fail back. found via gdb. Very short diff to format.c line 104 below. diff -urNab icecast-2.3.1.orig/src/format.c icecast-2.3.1/src/format.c ---

the problem is probably that nsvcap most likely tries to attach using the "shoutcast source" protocol, which is some strange variation of HTTP (but definitely not HTTP).... It's strange-ness and non-HTTP-ness is the reason why icecast doesn't support connecting the Shoutcast DSP to it. So I don't think any magical combination of headers will get live NSV

On Wed, Jun 25, 2003 at 03:33:25PM +1000, Michael Smith wrote: > > Is the metadata relayed to connecting clients. i.e. take a client that > supports shoutcast-style metadata, like winamp (and probably most others). > Connect as a listener to the relay. Do you get metadata? You should. If you > don't, the metadata relaying could have been broken (I think this is >

ices.conf: <Public>1</Public> <!-- The name of you stream, not the name of the song! --> <Name>Poohba's Urban Sounds</Name> <!-- Genre of your stream, be it rock or pop or whatever --> <Genre>RnB</Genre> icecast.xml <directory> <yp-url-timeout>15</yp-url-timeout>

On Friday 21 November 2003 13:17, Dave St John wrote: > Anyone know of the correct header that are sent to the icecast2 server? > > example the ones sent to a shoutcast server are > icy-name:whatever station > icy-genre:Industrial, EBM, Electronic > icy-pub:1 > icy-br:256 > icy-url:http://www.mediacast1.com > icy-reset:1 > > just need to know what the equivelant is

> I'll be posting some basic protocol ideas soon as I think I've finally > figured out how I want to handle stats and future admin functionality. I've written a mini liveice streamer/encoder built around the vorbis library, I need to know what connection protocol the new server will work around. (I'd get the icecast 2.0 sources, but once again the icecast source control

I am trying to set up Icecast and IceS. I have icecast 2.0.1 up and running. but when I try to start IceS 0.3 I get a seg fault. Here is the output: # /path/ices -r -c /confpath/ices.conf -F /playlistpath/playlist.pl -P password Logfile opened DEBUG: Sending following information to libshout: DEBUG: Stream: 0 DEBUG: Host: localhost:8001 (protocol: xaudiocast) DEBUG: Mount: /example1.mp3,

On 22 Mar 2003, Karl Heyes wrote: > ethereal is a good tool for that, start a capture (maybe with a capture > filter of "port <port>" or "host <ip>" to limit it if the box has plenty > of traffic), connect the source, wait a second then stop the capture. > Pick one of the packets that relates to the source stream and do > tools->follow tcp stream.

I thought the YP code was going to be fixed to use less resources so it could be used with other stream formats. It seems to be taking a long time. As it is now, Icecast2 is not a good solution for those wanting to be on a popular directory. I am forced to recommend using Shoutcast to my clients so they can get onto a popular directory. I would prefer to recommend Icecast2. Ross Levis.

At 11:35 PM 8/19/02 +0200, you wrote: >Hi, > >A question for the HTTP Basic auth for icecast2: what is the username to >use when doing such authentication. The related line in the login is: > >Authorization: Basic <base64 encoded string> > >where the <base64 encoded string> in its original form is: > >username:password > >now, what username is used?

> SOURCE $mountpoint ICE/1.0\n > ice-password: $password\n > ice-name: $name\n > ice-url: $url\n > ice-genre: $genre\n > ice-bitrate: $bitrate\n > ice-public: $public\n > ice-description: $description\n\n > Cool - I'll code this in right now.... There's no brains to this code right now, it just modifies the encoder example to read from teh soundcard and send

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

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 21 Mar 2003, Karl Heyes wrote: > There really isn't that much changed in ices wrt directory services, it > just invokes an added libshout API call on encode/reencode cases. Ices > could do with a tag to enable/disable it though. Check that you have > recent versions and if you still have the problem send me the http > headers that ices is sending. Well, it was current CVS

I am trying to connect to an icecast2 server that I have running on redhat 9. Via Ice0. Here are the errors that I am getting. Any help would be greatly appreciated. Kris. <p>[root@wyatt icecast]# ices -m mymp3stream -c ices.conf -P hackme Unknown Node: Server Unknown Execution keyword: Base_Directory Logfile opened DEBUG: Sending following information to libshout: DEBUG: Stream: 0

I've set up Icecast2 and IceS 0.3 (the version I'm told is better for mp3 streaming, which is what I want to do), but I can't figure out why IceS can't connect to Icecast2. Icecast2 starts with no complaints, and a portscan shows that it has opened the default port I've set it to (8000). However, IceS says it can't connect to it (both Icecast2 and IceS are on the

On Wed, Jun 25, 2003 at 11:34:07AM +1000, Michael Smith wrote: > > > 2) Should relay icy/x-audiocast stream metadata when connecting to > > icecast1/shoutcast/etc so that this information is available to YP > > Eh? It does. I even tested that with someone's shoutcast stream. It works. > Just add >

I'm relaying an icecast1 mp3 stream with icecast2. This works fine, and the song title is displayed correctly no matter if I use <relay-shoutcast-metadata>1</> or not on the relay. But, the stream name and other metadata provided by ices0 on the icecast1 server is not displayed in the listening client. Icecast1 source: [Id: 1] [Sock: 11] [Time of connect: 09/Aug/2004:10:01:24]