similar to: Icecast half open connection problem!.

Im running in a chroot'd environment: RH 9.0 lame-3.93.1 icecast-2.0.0 LiveIcePatched-1.0.0 xmms-1.2.7 I was able to get icecast running on port 8000, I was able to get liveice compiled and can see the .so file within xmms. Im pretty sure I have xmms configured to match my icecast config(passwords and mount points for source match). When I start up xmms I get the following error in my

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:

this is what i have so far that works, well sorda ------------------------ Content-type:audio/mpeg ice-mount:/crap ice-name:[L A T E X - T V] - LIVE!! ice-genre:Industrial, EBM, Electronic ice-public:0 ice-bitrate:280 ice-url:http://www.latexradio.com ice-description:boooo ice-audio-info:bitrate = 280, 152kbps video, 128kbps audio <p>content type works cant figure out the mount or how to

Hello When I replace ICY 200 by HTTP 200 then : - wget works - videolan VLC works (i thing its bad to send headers that it doesn't understand as it is one of the few crossplateform ogg players) So, I suggest, either to put something in the code to handle a different response header per stream type, or to put something in the config file (but then icecast admin have to bother with that) Or,

On Wednesday, 02 July 2003 at 19:19, Brendan Cully wrote: > 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. Per Jack's suggestion, here's a different version that forces icy mode when

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, I am trying to create a tarball from a 4.0.3 git checkout using "make dist", but it throws errors (small sample below, detailed Copy&Paste on request), and apart from this, www.oasis-open.org seems stale on connects from xsltproc, as can be seen in the lsof sample, below as well. Briefly and cheekily asked, is that normal? Are we all omitting docs in packaging at the moment?

__________________________________________________________________ New! Unlimited Netscape Internet Service. Only $9.95 a month -- Sign up today at http://isp.netscape.com/register Act now to get a personalized email address! Netscape. Just the Net You Need. <strong>attached mail follows:</strong><hr noshade> Im running in a chroot'd environment: RH 9.0 lame-3.93.1

__________________________________________________________________ New! Unlimited Netscape Internet Service. Only $9.95 a month -- Sign up today at http://isp.netscape.com/register Act now to get a personalized email address! Netscape. Just the Net You Need. <strong>attached mail follows:</strong><hr noshade> Im running in a chroot'd environment: RH 9.0 lame-3.93.1

I run two streams from ezstream via Icecast2 - one over http and one over https. In the ezstream config file I have defined two servers (http and https) and the two streams point to the different servers (by their names). But, if I go to the following two url's, Icecast report same (http-) 'streaming url' for both: https://radio.horsens-garage.rocks:8443/

> I'll try installing mozilla and downloading the plug-in. > Well maybe for some of us this will be little surprise. I've made a sucessful test using icecast 2.0 and the usual flash movie embedded on a web page, this time opened using Mozilla 1.5 (latest version). These are the headers I got: --------------- SUCCESSFUL 2.0 embedded in Mozilla -------------------- GET /live

Not all browsers support the ICY HTTP Streaming Protocol. For AAC, it requires ADTS support, which contrary to popular belief, IS NOT RAW. It is AAC frames in an audio transport stream, not video TS. To play this requires specific support, and it also needs to know about the embedded metadata, which once again, contrary to popular belief, ICY metadata IS NOT ID3vX. ICY MP3 streaming is similar,

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

Good afternoon, On Mon, 2018-10-29 at 13:48 -0400, Spencer Russell wrote: > I'm accessing a server using Icecast 2.4.0. It is streamed using HTTP > 1.1 using the Transfer-Encoding: chunked - so far so good. I feel like I need to clarify a few things here: * Icecast 2.4.0 does not implement HTTP/1.1 but HTTP/1.0, which it correctly tells in it's response status lines.

I'm accessing a server using Icecast 2.4.0. It is streamed using HTTP 1.1 using the Transfer-Encoding: chunked - so far so good. The issue is that the HTTP library I'm using uses connection pooling by default and attempts to re-use connections if the server does not send the "Connection: close" header. As part of that re-use, when you end a request/response cycle, it tries to

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

Hi Assorgia, I'm really happy you successfully got it with Mozilla. Where did you get the headers information? In Icecast2 logs? As soon as I know where to find the header information sent by IE, I will change the php script to cross the valid headers information sent by Mozilla with the necessary information needed by IE. The aim is to give Icecast the impression that the client is Mozilla.

Hi Dave, I remember I read your post, but when I read it, nobody had answered you yet. Thank you very much for the script, it seems to be more complete than mine. I am new to php, to create a script, I usually edit it in notepad and save it as *.php. How can I compile the script '--with-sockets' under windows? Thanks again MAX ________________________________________ From:

>>Or, keep as it is if it makes sense (I don't know the importance of >>having or not ICY) and then, see with videloan.org to update their player. >> >> > >Players should not be changed to support this. They're correct to reject it. > >Mike > > So, in that case, ICY 200 should be removed? btw, yesterday, after patching it to HTTP/1.0 200, I

> Thanks for the network dumps. As you say, it's weird because Flash, even > when embedded, can access the stream of Icecast2. I already noticed it by > analyzing Icecast2's logs as I wrote in the first message of this topic. > There is something I couldn't see in the network dumps: is the embedded > flash DOWNLOADING the stream even if it doesn't play it (with