similar to: Source Authentication URL and Params

Hi - I'm using Icecast to stream some audio that I embed in an <audio> tag on a webpage. This is working great for desktop browsers and on iOS, but it doesn't work on Android. It looks like Chrome mobile sends the header "Range: bytes=0-1" and then doesn't try to load any more data when Icecast responds with a 0 byte "HTTP/1.0 200 OK" response. From my

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

Hi, Could anyone tell me about the different login schemes sources can use to connect to IceCast, ShoutCast, etc? From what I can tell: ShoutCast uses something called icy login? IceCast uses something called x-audiocast, but can also use icy? IceCast2 uses what? Also, where can I find details about these login schemes? I sort of figured out a basic use of x-audiocast by looking at the JScream

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 >

Hey there, I''m in the muck of a major rails project, and need a bit of advice. Google isn''t much help in this case, so I came here. I''m trying to set up a URL structure as follows: url.com/username/blog/post_id where the user has_many posts and the post belongs_to user. I''m using the friendly_id plugin to enable easy lookup with the user''s username,

Greetings, tl;dr - I'm looking for sources to an Android Icecast client written in Java. long summary: I maintain an open source Android app (WREK Online) that plays the live mp3 stream from the station's Icecast server. Using the built in MediaPlayer class that is part of the Android SDK works OK. As a developer, I just give it the streaming URL of the Icecast server, hook up a few

At 04:30 PM 7/8/2003 -0400, you wrote: >On Tue, Jul 08, 2003 at 03:10:25PM -0500, oddsock wrote: > >Already checked that. this is the HTTP header for the stream: > >Content-Type: audio/mpeg >icy-bitrate:16 >icy-description:SF Indymedia >icy-genre:Talk >icy-name:Enemy Combatant Radio >icy-public:1 >icy-url:http://sf.indymedia.org/ >Server: Icecast 2.0-alpha2/cvs

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:

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 >

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

At 05:31 PM 6/25/2003 +1000, you wrote: > > I'm not concerned with how players see anything right now, tho that is a > > concern I guess. I'm concerned with getting the vitals - the stream > > name, genre, and description, to be relayed to a YP server when Icecast2 > > is relaying a Shoutcast stream. Currently it does not, this is missing > > functionality

No flash player can fetch the embedded metadata due to security restrictions concerning non-standard request headers which is required in order to get the embedded metadata. A patch for ice cast to allow this however is quite possible, perhaps a config directive that tells icecast not to wait for the specific request header and send the embedded metadata regardless of the icy-metadata header will

Hi After upgrading the kernel, everything is fine, except dovecot authentication. I get this trange thing (data after REQUEST? changed just in case it contains anything sensitive): Nov 29 16:56:01 volanges dovecot: auth: Error: BUG: Authentication client sent unknown handshake command: REQUEST?6970356762?616?6?235264ef69dbd1665538af54d12fdaea?session_pid=453?req... Nov 29 16:56:01 volanges

Hi everybody, I'm using dovecot-2.2.11 on NetBSD. After a kernel upgrade, while using the same dovecot binaries (they were working perfectly until today), I'm experiencing this error (more log at the end of my email): BUG: Authentication client sent unknown handshake command: REQUEST?227672066?18807?2?c717631d60216b2e9ec57a2fa69674b8?session_pid=16343?... I tried to build a newer

Hi, Some time ago my dovecot started to become BUGgy: Evertime I restart the system, dovecot is started but I cannot login. I see the following information in the logs: Jul 4 04:04:36 mail dovecot: auth: passwd-file(user,127.11.91.218,<nfkQjFT9vwCADFra>): no passwd file: /etc/dovecot/imap.passwd Jul 4 04:04:36 mail dovecot: auth: Error: BUG: Authentication client sent unknown handshake

At 03:58 PM 7/8/2003 -0400, you wrote: >That isnt the only bug. One one of our icecast servers the third >stream, sf-lofi.mp3, is not being announced to YP servers at all. On my >local diagnostics (logs all connections to the liveradio.indymedia.org >YP server) I see that icecast isnt even trying to add it. The other YP >servers are not showing this stream either. It doesnt

So, I'm in the middle of understanding how the icecast.xml file is parsed, and how the settings for a specific mount point are read. In cfgfile.c - _parse_mount() I've added the following lines: } else if (xmlStrcmp (node->name, XMLSTR("playlist-notify-uri")) == 0) { mount->playlist_notify_uri = (char *)xmlNodeListGetString (doc, node->xmlChildrenNode, 1); }

Hi again. I just compiled icecast 2. It seemed ok but at the end I got this: /usr/bin/ld: warning: libcom_err.so.2, needed by /usr/lib/libcurl.so, may conflict with libcom_err.so.3 Is this anything I have to take care of? Can you explain what it means? Thanx, Luke <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage:

# HG changeset patch # User Carl-Daniel Hailfinger <Carl-Daniel.Hailfinger@inf.h-brs.de> # Date 1474903734 -7200 # Mon Sep 26 17:28:54 2016 +0200 # Node ID dbd1ea0a401cedcfa426097a289d852971b14f1e # Parent d7d5078d08c711032837dcac79a4450226ec2ce5 nbdkit: Fix flags in old-style connection diff -r d7d5078d08c7 -r dbd1ea0a401c src/connections.c --- a/src/connections.c Sun Sep 25 05:04:02