After encountering a mysterious problem with Icecast 2.0 and streaming to Flash within IE for Windows, we've had to roll back to Icecast 1.3.12 2.0 Problem here: http://lists.xiph.org/pipermail/icecast/2004-October/007726.html Of course, I'm now having problems installing Icecast 1.3.12. When running gmake or make after ./configure with or without the --with-libwrap or --with-crypt flags it craps out with an error (below). Installation cannot proceed. This is on a Redhat Linux 9.0 box. Is there ANY way to fix this? -Ian. ---- Transcript follows: [root@asl147 icecast-1.3.12]# gmake gmake all-recursive gmake[1]: Entering directory `/home/pulverradio/icecast/icecast-1.3.12' Making all in src gmake[2]: Entering directory `/home/pulverradio/icecast/icecast-1.3.12/src' Making all in authenticate gmake[3]: Entering directory `/home/pulverradio/icecast/icecast-1.3.12/src/authenticate' [..STUFF DELETED..] gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -g -O2 -Wall -c pool.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -g -O2 -Wall -c interpreter.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -g -O2 -Wall -c vsnprintf.c gcc -g -O2 -Wall -o icecast main.o client.o admin.o source.o connection.o log.o directory.o commands.o sock.o threads.o logtime.o commandline.o utility.o avl.o avl_functions.o match.o relay.o timer.o alias.o restrict.o static.o http.o ice_string.o dir.o vars.o memory.o ice_resolv.o item.o pool.o interpreter.o vsnprintf.o authenticate/libauthenticate.a -lm -lpthread commands.o(.text+0x406e): In function `com_dump': /home/pulverradio/icecast/icecast-1.3.12/src/commands.c:2149: undefined reference to `errno' collect2: ld returned 1 exit status gmake[3]: *** [icecast] Error 1 gmake[3]: Leaving directory `/home/pulverradio/icecast/icecast-1.3.12/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/pulverradio/icecast/icecast-1.3.12/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/pulverradio/icecast/icecast-1.3.12' gmake: *** [all-recursive-am] Error 2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2132 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast/attachments/20041102/bb1787cf/attachment-0001.bin
On Wednesday 03 November 2004 04:27, Ian Andrew Bell wrote:> After encountering a mysterious problem with Icecast 2.0 and streaming > to Flash within IE for Windows, we've had to roll back to Icecast > 1.3.12 > > 2.0 Problem here: > http://lists.xiph.org/pipermail/icecast/2004-October/007726.html > > Of course, I'm now having problems installing Icecast 1.3.12.The website is, I think, very clear that 1.x is completely unsupported by us. It even specifically says not to ask us about it. You're encountering (probably, I can't check the URL you gave right now) a flash bug, that nobody has suggested a reasonable approach to avoiding. It has been suggested that the problem is that flash can't cope with not getting a content-length header. The problem, of course, is that an icecast stream HAS no well-defined length. We also don't set content-length on served files; that should probably be considered a bug. I wonder if flash can cope with http/1.1 chunked transfer encodings (this is the HTTP/1.1 way of signalling a well-defined length to an HTTP response (or request, but many implementations screw that bit up) where the length is not known in advance)? If it does, we could implement that (as an optional thing, at least). Mike