similar to: details of HTTP Basic auth for icecast2

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?

Michael Smith wrote: > Currently, "source". Other suggestions welcome. I see. I guess the current working semantics don't need anything more complicated. If the need rises to provide more complex access control, userid / password pairs could be defined in the icecast config file. e.g.: user1 / password1 allowed to connect as source /source1* user2 / password2 allowed to

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

> 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

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

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

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

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 >

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

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>

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 Thursday, 15 April 2004 at 08:07, Kristoffer R. Munroe wrote: > I am using the http protocol now and I still get the same results. <snip> > >DEBUG: Sending following information to libshout: > >DEBUG: Stream: 0 > >DEBUG: Host: 127.0.0.1:8000 (protocol: xaudiocast) According to the log file you attached, you're still using xaudiocast. Double check your

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 >

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.

Can anybody help me, I have Icecast2 and Ices2 on Mandrake and want to play a static playlist. I am getting the following problem: [2003-06-26 12:56:08] DBUG connection/_handle_get_request Client connected [2003-06-26 12:56:08] DBUG admin/admin_handle_request Got command (streamlist) [2003-06-26 12:56:08] INFO admin/admin_handle_request Bad or missing password on admin command request

Unfortunately, ices2 isn't writing anything to the logs. I've got them on debug mode, but there still isn't anything being written to indicate it's having a known problem. As far as the interference goes, I've found that reducing the iGain and amping the input source seems to reduce the interfencence a good deal, at least, good enough such that it's only a low murmur in

I can understand wanting to boost the adoption of Xiph codecs, but I think restricting the directory to vorbis streams only will not help this endeavour. I can imagine it will just piss a lot of people, including myself, and give Xiph a bad name. I get very few listeners of my AAC+ stream now since this occured. The restriction is not an insentive to switch to Ogg Vorbis at all. The incentive

> 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

On Wed, Jun 25, 2003 at 04:27:58PM +1000, Michael Smith wrote: > > > > notice that, with exception of the last, they're all ice-* not icy-*... > > prehaps this is incompatable with the way most players operate to get > > stream data? Is this a typo? > > No. This is deliberate. There could be a bug in the code that takes these > headers and puts bits of them