From segler_alex at web.de Thu Oct 15 09:15:46 2009 From: segler_alex at web.de (segler_alex) Date: Thu, 15 Oct 2009 11:15:46 +0200 Subject: [Icecast] dir.xiph.org/yp.xml Message-ID: <1255598146.3936.2.camel@gaia> Hello, i programmed an icecast plugin for rhythmbox. My question is: why are not all informations about the radio stations exposed to dir.xiph.org/yp.xml ? I really would love it to have at least the website of the station in the xml. greatings segler_alex From johnlist at gulfbridge.net Sat Oct 17 23:43:16 2009 From: johnlist at gulfbridge.net (John Hicks) Date: Sat, 17 Oct 2009 19:43:16 -0400 Subject: [Icecast] How to get listed in dir.xiph.org? Message-ID: <4ADA5694.1050109@gulfbridge.net> I've been trying to tweak my icecast.xml file to get listed in xip.xiph.org, but am not making any progress. I'm running icecast 2.3.1 and darkice 0.19 Here are what I think are the relvant parts of icecast.xml:

http://dir.xiph.org/cgi-bin/yp-cgi

and

/stream.ogg

/Silence.ogg

1 I don't see anything in my darkice.cfg file that is yp specific. Am I doing something wrong? How often is the directory refreshed? (How patient should I be?) Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoff at QuiteLikely.com Sun Oct 18 00:15:18 2009 From: geoff at QuiteLikely.com (Geoff Shang) Date: Sun, 18 Oct 2009 02:15:18 +0200 (IST) Subject: [Icecast] How to get listed in dir.xiph.org? In-Reply-To: <4ADA5694.1050109@gulfbridge.net> References: <4ADA5694.1050109@gulfbridge.net> Message-ID: On Sat, 17 Oct 2009, John Hicks wrote: > I'm running icecast 2.3.1 and darkice 0.19 [snip] > I don't see anything in my darkice.cfg file that is yp specific. You need public = yes in the stanza of the config file which relates to your streaming configuration (e.g. [icecast2-0]) I don't know what the default state is if this is not present, but I wouldn't be surprised if it defaults to no. Geoff. From karl at xiph.org Sun Oct 18 03:19:48 2009 From: karl at xiph.org (Karl Heyes) Date: Sun, 18 Oct 2009 04:19:48 +0100 Subject: [Icecast] How to get listed in dir.xiph.org? In-Reply-To: <4ADA5694.1050109@gulfbridge.net> References: <4ADA5694.1050109@gulfbridge.net> Message-ID: <4ADA8954.5060206@xiph.org> On 18/10/09 00:43, John Hicks wrote: > I've been trying to tweak my icecast.xml file to get listed in > xip.xiph.org, but am not making any progress. > I'm running icecast 2.3.1 and darkice 0.19 > > Here are what I think are the relvant parts of icecast.xml: > > 15 > http://dir.xiph.org/cgi-bin/yp-cgi > > and > > /stream.ogg > /Silence.ogg > 1 > 0 > 0 > 1 > > How often is the directory refreshed? (How patient should I be?) The public setting here is an override mainly for on-demand relays but you should find a setting in the source client (as Geoff suggested). Besides that check the icecast error log, if YP support is disabled then that will be reported also if there is an error in adding the entry then the error will be logged (eg an invalid hostname). While icecast may only add the entry after about a minute, the directory should show the entry fairly quickly after that. karl. From johnlist at gulfbridge.net Sun Oct 18 05:21:02 2009 From: johnlist at gulfbridge.net (John Hicks) Date: Sun, 18 Oct 2009 01:21:02 -0400 Subject: [Icecast] How to get listed in dir.xiph.org? Solved: Use domain name without http:// for webhost In-Reply-To: <4ADA8954.5060206@xiph.org> References: <4ADA5694.1050109@gulfbridge.net> <4ADA8954.5060206@xiph.org> Message-ID: <4ADAA5BE.1020704@gulfbridge.net> Karl Heyes wrote: > On 18/10/09 00:43, John Hicks wrote: >> I've been trying to tweak my icecast.xml file to get listed in >> xip.xiph.org, but am not making any progress. >> I'm running icecast 2.3.1 and darkice 0.19 >> >> Here are what I think are the relvant parts of icecast.xml: >> >> 15 >> http://dir.xiph.org/cgi-bin/yp-cgi >> >> and >> >> /stream.ogg >> /Silence.ogg >> 1 >> 0 >> 0 >> 1 >> > >> How often is the directory refreshed? (How patient should I be?) > > The public setting here is an override mainly for on-demand relays but > you should find a setting in the source client (as Geoff suggested). > Besides that check the icecast error log, if YP support is disabled > then that will be reported also if there is an error in adding the > entry then the error will be logged (eg an invalid hostname). While > icecast may only add the entry after about a minute, the directory > should show the entry fairly quickly after that. > > karl. Bingo! Following your suggestion, I checked my Icecast error log (duh) and found: EROR yp/send_to_yp YP add on http://dir.xiph.org/cgi-bin/yp-cgi failed: Add refused. Reason: Illegal listen_url. Incorrect . After trying all sorts of different combinations and permutations of my URL (with and without the port, with and without the tailing slash) in the entry of my icecast.xml, I finally stumbled on using the domain name only (without the http://). mydomain.com That did the trick! Thanks for the help, Karl (and Jiri and Jeff and Bryan)! John -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.j.wierenga at gmail.com Sun Oct 18 13:52:36 2009 From: k.j.wierenga at gmail.com (Klaas Jan Wierenga) Date: Sun, 18 Oct 2009 15:52:36 +0200 Subject: [Icecast] icecast-2.3.2-kh17 versus icecast-2.3.2 Message-ID: <2830F7FD-3D93-4312-A543-E5F0AA983A60@gmail.com> Hi, I've been using icecast-2.3.1 for some time now and it is really working well for me, solid as a rock (no crashes) and running 100's of streams and 1000's of listeners, but in order to support authentication and have easier configuration I want to start using the url authentication (esp. the stream_auth) and mount-name wildcards that are supported by icecast-2.3.2-kh17. I am unsure about the stability of icecast-2.3.2-kh17 when using url authentication for both stream and listener authentication. What are the major differences between icecast-2.3.2 and the kh17 branch and can you say anything about the stability of icecast-2.3.2-kh17 in production use? Any feedback is very much appreciated. Regards, Klaas Jan Wierenga From segler_alex at web.de Sun Oct 18 16:45:54 2009 From: segler_alex at web.de (segler_alex) Date: Sun, 18 Oct 2009 18:45:54 +0200 Subject: [Icecast] informations in yp.xml on dir.xiph.org Message-ID: <1255884354.12874.2.camel@gaia> Hello, I'm working on a plugin for rhythmbox that displays icecast streams with in infos from yp.xml My question is: why are not all informations available through the webpage on dir.xiph.org available in the yp.xml? Thanks in advance segler_alex -- Bitte senden Sie mir keine Word- oder PowerPoint-Anh?nge. Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html From karl at xiph.org Mon Oct 19 01:00:03 2009 From: karl at xiph.org (Karl Heyes) Date: Mon, 19 Oct 2009 02:00:03 +0100 Subject: [Icecast] icecast-2.3.2-kh17 versus icecast-2.3.2 In-Reply-To: <2830F7FD-3D93-4312-A543-E5F0AA983A60@gmail.com> References: <2830F7FD-3D93-4312-A543-E5F0AA983A60@gmail.com> Message-ID: <4ADBBA13.3010708@xiph.org> On 18/10/09 14:52, Klaas Jan Wierenga wrote: > Hi, > > I've been using icecast-2.3.1 for some time now and it is really > working well for me, solid as a rock (no crashes) and running 100's of > streams and 1000's of listeners, but in order to support > authentication and have easier configuration I want to start using the > url authentication (esp. the stream_auth) and mount-name wildcards > that are supported by icecast-2.3.2-kh17. > > I am unsure about the stability of icecast-2.3.2-kh17 when using url > authentication for both stream and listener authentication. What are > the major differences between icecast-2.3.2 and the kh17 branch and > can you say anything about the stability of icecast-2.3.2-kh17 in > production use? kh17 hasn't been out for that long but I've had no problems reported about it. URL auth should be stable, there's been a fair amount of testing recently using URL auth because of the per-listener intro content feature recently added. The main difference between them is the threading structure. With 2.3.2/trunk you have one thread per stream setup, which is fine for low numbers of streams but some are running many streams which means the loading on the server can be a problem. In the kh branch, the threads are limited by the setting, so you get a lot less switching between threads if you have say 100+ streams. There are other functional features that seem to be working well, like the wildcard mounts, average bitrate stats, bandwidth limiting per mount. Sending content from a fallback file is now throttled which was an issue under 2.3.2 for some people. Relays can have multiple server references (for when one fails). Some extra options are available for auth such as sending the listener to an alternative mountpoint on failure. master/slave setups are handled differently now. A slave relay uses an /admin link to retrieve the content. This means two things, that the slave connection can bypass the usual limits (max-listeners etc) and that an auth can be applied for the connection meaning that each slave can have their own user/pass. The stream auth support has already been merged into trunk although not for shoutcast style source clients. kh17 does allow a shoutcast source to use url auth. karl. From andreas.bergstrom at hiof.no Tue Oct 27 09:09:22 2009 From: andreas.bergstrom at hiof.no (=?iso-8859-1?Q?Andreas_Bergstr=F8m?=) Date: Tue, 27 Oct 2009 10:09:22 +0100 Subject: [Icecast] Vorbis still glitching on metadata update? Message-ID: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> Greetings, I am trying to track down a bug with intermittant glitching in our Vorbis streams. I am running Icecast 2.3.2 on Ubuntu 9.04. Several Vorbis clients seem to glitch on some (not all) metadata updates. As we update metadata 3 to 4 times a minute, this is something we are trying to fix, VLC gives the following output on metadata update: main warning: the mixer got a packet in the past (22371) main warning: the mixer got a packet in the past (1038) main warning: mixer start isn't output start (398) ogg debug: end of a group of logical streams ogg debug: found vorbis header ogg debug: will reuse old stream to avoid glitch ogg debug: beginning of a group of logical streams main error: ES_OUT_RESET_PCR called main warning: received buffer in the future main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 19% main debug: Buffering 40% main debug: Buffering 63% main debug: End of audio preroll main debug: Buffering 84% main debug: Stream buffering done (1274 ms in 144 ms) main debug: Decoder buffering done in 0 ms For testing you can compare: http://radio.hiof.no/nrk-jazz-128 (MP3 stream, no glitching) http://radio.hiof.no/nrk-jazz-128.ogg (Vorbis stream, glitches) Metadata is updated via the web admin interface from a script. Has anyone else encountered this or know a way to fix this issue? Regards, -- Andreas Bergstr?m ?stfold University College Dept. of Computer Sciences Tel: +47 69 21 53 71 http://media.hiof.no/ From petr.pisar at atlas.cz Tue Oct 27 10:14:01 2009 From: petr.pisar at atlas.cz (Petr Pisar) Date: Tue, 27 Oct 2009 11:14:01 +0100 Subject: [Icecast] Vorbis still glitching on metadata update? In-Reply-To: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> Message-ID: <20091027101356.GG3536@album.bayer.ipv6ia.org> On Tue, Oct 27, 2009 at 10:09:22AM +0100, Andreas Bergstr?m wrote: > > Several Vorbis clients seem to glitch on some (not all) metadata > updates. As we update metadata 3 to 4 times a minute, this is > something we are trying to fix, VLC gives the following output on > metadata update: > [?] > http://radio.hiof.no/nrk-jazz-128.ogg (Vorbis stream, glitches) > MPlayer plays very well, moc (music on console) too (but it reports `Stream error' on each meatadata update). Reference implementation ogg123 produces glitches. It says ALSA underrun and rebufferes the stream. All players tested with 128 kB buffer. BTW, I your IPv6 streams do not work because: $ ping6 -n radio.ipv6.hiof.no PING radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) 56 data bytes From 2001:700:0:1003::2 icmp_seq=1 Destination unreachable: Address unreachable -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From andreas.bergstrom at hiof.no Tue Oct 27 11:11:19 2009 From: andreas.bergstrom at hiof.no (=?iso-8859-1?Q?Andreas_Bergstr=F8m?=) Date: Tue, 27 Oct 2009 12:11:19 +0100 Subject: [Icecast] Vorbis still glitching on metadata update? In-Reply-To: <20091027101356.GG3536@album.bayer.ipv6ia.org> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> <20091027101356.GG3536@album.bayer.ipv6ia.org> Message-ID: <1AE9F48C-F0B7-42F9-9159-66196117678C@hiof.no> On 27. okt. 2009, at 11:14, Petr Pisar wrote: > MPlayer plays very well, moc (music on console) too (but it reports `Stream > error' on each meatadata update). OK, thank you. > Reference implementation ogg123 produces glitches. It says ALSA > underrun and > rebufferes the stream. So could be clientside, could be serverside, time to dig deeper, I guess. > All players tested with 128 kB buffer. > > BTW, I your IPv6 streams do not work because: > > $ ping6 -n radio.ipv6.hiof.no > PING radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) 56 > data bytes > From 2001:700:0:1003::2 icmp_seq=1 Destination unreachable: Address > unreachable Ah thanks, found a configuration error, it _should_ work now. Regards, -- Andreas Bergstr?m ?stfold University College Dept. of Computer Sciences Tel: +47 69 21 53 71 http://media.hiof.no/ From dm8tbr at afthd.tu-darmstadt.de Tue Oct 27 13:11:38 2009 From: dm8tbr at afthd.tu-darmstadt.de (Thomas B. Ruecker) Date: Tue, 27 Oct 2009 13:11:38 +0000 Subject: [Icecast] Vorbis still glitching on metadata update? In-Reply-To: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> Message-ID: <4AE6F18A.20101@afthd.tu-darmstadt.de> Hi, Andreas Bergstr?m schrieb: > Metadata is updated via the web admin interface from a script. > sorry for stating the obvious: Injecting the metadata directly within the source client is not an option for you? Maybe Karl can say something about the metadata update? Cheers Thomas From karl at xiph.org Tue Oct 27 16:40:02 2009 From: karl at xiph.org (Karl Heyes) Date: Tue, 27 Oct 2009 16:40:02 +0000 Subject: [Icecast] Vorbis still glitching on metadata update? In-Reply-To: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> Message-ID: <4AE72262.1020303@xiph.org> On 27/10/09 09:09, Andreas Bergstr?m wrote: > Greetings, > > I am trying to track down a bug with intermittant glitching in our > Vorbis streams. > > I am running Icecast 2.3.2 on Ubuntu 9.04. > > Several Vorbis clients seem to glitch on some (not all) metadata > updates. As we update metadata 3 to 4 times a minute, this is > something we are trying to fix, VLC gives the following output on > metadata update: > For testing you can compare: > > http://radio.hiof.no/nrk-jazz-128 (MP3 stream, no glitching) > http://radio.hiof.no/nrk-jazz-128.ogg (Vorbis stream, glitches) inserts for ogg are different to mp3. It is generally better to get the source client to do that as it will be in sync with the content. > Metadata is updated via the web admin interface from a script. > > Has anyone else encountered this or know a way to fix this issue? > from here, ogg123 is ok (although a 128k buffer, not sure what the prebuffer % is, seems to be low, try increasing those). mplayer is fine but vlc keeps resetting itself in a major way on a new logical stream. The format of the stream looks ok, I don't see any specific issue with it. There is one other thing I can check but I'll have to get back to you on that. karl. From petr.pisar at atlas.cz Tue Oct 27 17:14:52 2009 From: petr.pisar at atlas.cz (Petr Pisar) Date: Tue, 27 Oct 2009 18:14:52 +0100 Subject: [Icecast] Vorbis still glitching on metadata update? In-Reply-To: <4AE72262.1020303@xiph.org> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> <4AE72262.1020303@xiph.org> Message-ID: <20091027171449.GJ3536@album.bayer.ipv6ia.org> On Tue, Oct 27, 2009 at 04:40:02PM +0000, Karl Heyes wrote: > On 27/10/09 09:09, Andreas Bergstr?m wrote: > > http://radio.hiof.no/nrk-jazz-128.ogg (Vorbis stream, glitches) > > from here, ogg123 is ok (although a 128k buffer, not sure what the > prebuffer % is, seems to be low, try increasing those). I check it out with bigger buffer (size 512 kB, prebuffer 80 %) again and it sounds perfectly now. Maybe mplayer has better TCP tunning than ogg123 because the buffer fill stays around 37--40 % but ogg123 shows decreasing fill periodically with 128kB buffer. -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From eric at sfu.ca Tue Oct 27 21:49:18 2009 From: eric at sfu.ca (Eric Kolotyluk) Date: Tue, 27 Oct 2009 14:49:18 -0700 Subject: [Icecast] Who sets the mount point? In-Reply-To: <20091027171449.GJ3536@album.bayer.ipv6ia.org> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> <4AE72262.1020303@xiph.org> <20091027171449.GJ3536@album.bayer.ipv6ia.org> Message-ID: <4AE76ADE.8000706@sfu.ca> Sorry for what seems like a real newbie question, but who actually sets the mount point? Is it the client/source, the icecast.xml file, or both? I find the IceCast configuration documentation quite confusing as it does not really explain mount points very well. If someone would take the time to explain things to me I would volunteer to improve the documentation. Case in point. I've been using IceCast for years, but never really understood what I was doing. Recently I installed IceCast 2.3.1 on my new computer. I have not configured anything - everything is the default out of the box experience. As far as I can tell the default icecast.xml file does not actually have any mount points defined, they are all commented out. Am I correct? I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast locked on to the first mount point I configured in ODDCAST, which happened to be example-complex.ogg, and now I cannot seem to change it. Is this how IceCast works, it takes whatever the client/source sends it and then automatically creates a mount point? My problem now is my ODDCAST DSP seems to be locked into example-complex.ogg as its 'destination' and won't release it even when I change the mount point in the DSP Config settings. I would like to change the mount point to something else, but I cannot figure out how. Has the mount point "example-complex.ogg" been locked into my Winamp configuration somewhere, or is something in the IceCast configuration that is forcing this mount point? I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still thinks it's configured to "example-complex.ogg" even though it has not connected to IceCast yet. I suspect there is some magic winamp/oddcast config file somewhere, but I am unable to find it (as Windows search mechanism is hopelessly lame). Cheers, Eric From asoprocoin at yahoo.com Tue Oct 27 23:33:53 2009 From: asoprocoin at yahoo.com (Edgardo Alfonso Tapia del Valle) Date: Tue, 27 Oct 2009 16:33:53 -0700 (PDT) Subject: [Icecast] Icecast Digest, Vol 65, Issue 4 In-Reply-To: Message-ID: <935112.68899.qm@web58408.mail.re3.yahoo.com> Amigos: Ser?a posible que sus comentarios, sugerenciaas, invitaciones, consultas, opiniones, los pueda recibir en idioma espa?ol? Atentamente: Edgardo Tapia --- El mar 27-oct-09, icecast-request at xiph.org escribi?: > De: icecast-request at xiph.org > Asunto: Icecast Digest, Vol 65, Issue 4 > A: icecast at xiph.org > Fecha: martes, 27 octubre, 2009, 4:00 pm > Send Icecast mailing list submissions > to > ??? icecast at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > ??? http://lists.xiph.org/mailman/listinfo/icecast > or, via email, send a message with subject or body 'help' > to > ??? icecast-request at xiph.org > > You can reach the person managing the list at > ??? icecast-owner at xiph.org > > When replying, please edit your Subject line so it is more > specific > than "Re: Contents of Icecast digest..." > > > Today's Topics: > > ???1. Vorbis still glitching on metadata > update? (Andreas Bergstr?m) > ???2. Re: Vorbis still glitching on metadata > update? (Petr Pisar) > ???3. Re: Vorbis still glitching on metadata > update? (Andreas Bergstr?m) > ???4. Re: Vorbis still glitching on metadata > update? (Thomas B. Ruecker) > ???5. Re: Vorbis still glitching on metadata > update? (Karl Heyes) > ???6. Re: Vorbis still glitching on metadata > update? (Petr Pisar) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Oct 2009 10:09:22 +0100 > From: Andreas Bergstr?m > Subject: [Icecast] Vorbis still glitching on metadata > update? > To: icecast at xiph.org > Message-ID: <9B992C70-CAAD-401F-8A8E-0457DBD0E601 at hiof.no> > Content-Type: text/plain; charset=iso-8859-1; > format=flowed; delsp=yes > > Greetings, > > I am trying to track down a bug with intermittant glitching > in our? > Vorbis streams. > > I am running Icecast 2.3.2 on Ubuntu 9.04. > > Several Vorbis clients seem to glitch on some (not all) > metadata? > updates. As we update metadata 3 to 4 times a minute, this > is? > something we are trying to fix, VLC gives the following > output on? > metadata update: > > main warning: the mixer got a packet in the past (22371) > main warning: the mixer got a packet in the past (1038) > main warning: mixer start isn't output start (398) > ogg debug: end of a group of logical streams > ogg debug: found vorbis header > ogg debug: will reuse old stream to avoid glitch > ogg debug: beginning of a group of logical streams > main error: ES_OUT_RESET_PCR called > main warning: received buffer in the future > main debug: Buffering 0% > main debug: Buffering 0% > main debug: Buffering 19% > main debug: Buffering 40% > main debug: Buffering 63% > main debug: End of audio preroll > main debug: Buffering 84% > main debug: Stream buffering done (1274 ms in 144 ms) > main debug: Decoder buffering done in 0 ms > > For testing you can compare: > > http://radio.hiof.no/nrk-jazz-128 (MP3 stream, no > glitching) > http://radio.hiof.no/nrk-jazz-128.ogg > (Vorbis stream, glitches) > > Metadata is updated via the web admin interface from a > script. > > Has anyone else encountered this or know a way to fix this > issue? > > Regards, > > -- > Andreas Bergstr?m > ?stfold University College > Dept. of Computer Sciences > Tel: +47 69 21 53 71 > http://media.hiof.no/ > > > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 27 Oct 2009 11:14:01 +0100 > From: Petr Pisar > Subject: Re: [Icecast] Vorbis still glitching on metadata > update? > To: icecast at xiph.org > Message-ID: <20091027101356.GG3536 at album.bayer.ipv6ia.org> > Content-Type: text/plain; charset="utf-8" > > On Tue, Oct 27, 2009 at 10:09:22AM +0100, Andreas Bergstr?m > wrote: > > > > Several Vorbis clients seem to glitch on some (not > all) metadata? > > updates. As we update metadata 3 to 4 times a minute, > this is? > > something we are trying to fix, VLC gives the > following output on? > > metadata update: > > > [?] > > http://radio.hiof.no/nrk-jazz-128.ogg > (Vorbis stream, glitches) > > > MPlayer plays very well, moc (music on console) too (but it > reports `Stream > error' on each meatadata update). > > Reference implementation ogg123 produces glitches. It says > ALSA underrun and > rebufferes the stream. > > All players tested with 128 kB buffer. > > BTW, I your IPv6 streams do not work because: > > $ ping6 -n radio.ipv6.hiof.no > PING > radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) 56 > data bytes > From 2001:700:0:1003::2 icmp_seq=1 Destination unreachable: > Address unreachable > > -- Petr > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 190 bytes > Desc: not available > Url : http://lists.xiph.org/pipermail/icecast/attachments/20091027/a6c2eabe/attachment-0001.pgp > > > ------------------------------ > > Message: 3 > Date: Tue, 27 Oct 2009 12:11:19 +0100 > From: Andreas Bergstr?m > Subject: Re: [Icecast] Vorbis still glitching on metadata > update? > To: icecast at xiph.org > Message-ID: <1AE9F48C-F0B7-42F9-9159-66196117678C at hiof.no> > Content-Type: text/plain; charset=iso-8859-1; > format=flowed; delsp=yes > > > On 27. okt. 2009, at 11:14, Petr Pisar wrote: > > MPlayer plays very well, moc (music on console) too > (but it reports? > `Stream > > error' on each meatadata update). > > OK, thank you. > > > Reference implementation ogg123 produces glitches. It > says ALSA? > > underrun and > > rebufferes the stream. > > So could be clientside, could be serverside, time to dig > deeper, I? > guess. > > > All players tested with 128 kB buffer. > > > > BTW, I your IPv6 streams do not work because: > > > > $ ping6 -n radio.ipv6.hiof.no > > PING > radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) > 56? > > data bytes > > From 2001:700:0:1003::2 icmp_seq=1 Destination > unreachable: Address? > > unreachable > > > Ah thanks, found a configuration error, it _should_ work > now. > > Regards, > > -- > Andreas Bergstr?m > ?stfold University College > Dept. of Computer Sciences > Tel: +47 69 21 53 71 > http://media.hiof.no/ > > > > > > > > ------------------------------ > > Message: 4 > Date: Tue, 27 Oct 2009 13:11:38 +0000 > From: "Thomas B. Ruecker" > Subject: Re: [Icecast] Vorbis still glitching on metadata > update? > To: Icecast > Message-ID: <4AE6F18A.20101 at afthd.tu-darmstadt.de> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > Hi, > > Andreas Bergstr?m schrieb: > > Metadata is updated via the web admin interface from a > script. > >??? > > sorry for stating the obvious: > Injecting the metadata directly within the source client is > not an > option for you? > > > Maybe Karl can say something about the metadata update? > > Cheers > > Thomas > > > ------------------------------ > > Message: 5 > Date: Tue, 27 Oct 2009 16:40:02 +0000 > From: Karl Heyes > Subject: Re: [Icecast] Vorbis still glitching on metadata > update? > To: icecast at xiph.org > Message-ID: <4AE72262.1020303 at xiph.org> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > On 27/10/09 09:09, Andreas Bergstr?m wrote: > > Greetings, > > > > I am trying to track down a bug with intermittant > glitching in our > > Vorbis streams. > > > > I am running Icecast 2.3.2 on Ubuntu 9.04. > > > > Several Vorbis clients seem to glitch on some (not > all) metadata > > updates. As we update metadata 3 to 4 times a minute, > this is > > something we are trying to fix, VLC gives the > following output on > > metadata update: > > > For testing you can compare: > > > > http://radio.hiof.no/nrk-jazz-128 (MP3 > stream, no glitching) > > http://radio.hiof.no/nrk-jazz-128.ogg > (Vorbis stream, glitches) > > inserts for ogg are different to mp3. It is generally > better to get the > source client to do that as it will be in sync with the > content. > > > Metadata is updated via the web admin interface from a > script. > > > > Has anyone else encountered this or know a way to fix > this issue? > > > > from here, ogg123 is ok (although a 128k buffer, not sure > what the > prebuffer % is, seems to be low, try increasing > those).? mplayer is fine > but vlc keeps resetting itself in a major way on a new > logical stream. > The format of the stream looks ok, I don't see any specific > issue with > it. There is one other thing I can check but I'll have to > get back to > you on that. > > karl. > > > > ------------------------------ > > Message: 6 > Date: Tue, 27 Oct 2009 18:14:52 +0100 > From: Petr Pisar > Subject: Re: [Icecast] Vorbis still glitching on metadata > update? > To: icecast at xiph.org > Message-ID: <20091027171449.GJ3536 at album.bayer.ipv6ia.org> > Content-Type: text/plain; charset="utf-8" > > On Tue, Oct 27, 2009 at 04:40:02PM +0000, Karl Heyes > wrote: > > On 27/10/09 09:09, Andreas Bergstr?m wrote: > > > > http://radio.hiof.no/nrk-jazz-128.ogg > (Vorbis stream, glitches) > > > > from here, ogg123 is ok (although a 128k buffer, not > sure what the > > prebuffer % is, seems to be low, try increasing > those). > > I check it out with bigger buffer (size 512 kB, prebuffer > 80 %) again > and it sounds perfectly now. Maybe mplayer has better TCP > tunning than > ogg123 because the buffer fill stays around 37--40 % but > ogg123 shows > decreasing fill periodically with 128kB buffer. > > -- Petr > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 190 bytes > Desc: not available > Url : http://lists.xiph.org/pipermail/icecast/attachments/20091027/cced5677/attachment-0001.pgp > > > ------------------------------ > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > > End of Icecast Digest, Vol 65, Issue 4 > ************************************** > __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.espanol.yahoo.com/ From eric at zhevny.com Tue Oct 27 23:48:48 2009 From: eric at zhevny.com (Eric Dantan Rzewnicki) Date: Tue, 27 Oct 2009 19:48:48 -0400 Subject: [Icecast] Who sets the mount point? In-Reply-To: <4AE76ADE.8000706@sfu.ca> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> <4AE72262.1020303@xiph.org> <20091027171449.GJ3536@album.bayer.ipv6ia.org> <4AE76ADE.8000706@sfu.ca> Message-ID: <20091027234847.GF16443@zhevny.com> On Tue, Oct 27, 2009 at 02:49:18PM -0700, Eric Kolotyluk wrote: > Sorry for what seems like a real newbie question, but who actually sets > the mount point? Is it the client/source, the icecast.xml file, or both? As I understand it, a source client has to specify a mount point when it connects. If that mount point was already specified in the icecast server config, then the associated mount options will be applied. If the client specified mount point was not previously known to icecast, then a new mount point with the name given by the source client is created. -Eric Rz. From karl at xiph.org Wed Oct 28 00:49:57 2009 From: karl at xiph.org (Karl Heyes) Date: Wed, 28 Oct 2009 00:49:57 +0000 Subject: [Icecast] Who sets the mount point? In-Reply-To: <20091027234847.GF16443@zhevny.com> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> <4AE72262.1020303@xiph.org> <20091027171449.GJ3536@album.bayer.ipv6ia.org> <4AE76ADE.8000706@sfu.ca> <20091027234847.GF16443@zhevny.com> Message-ID: <4AE79535.4000703@xiph.org> On 27/10/09 23:48, Eric Dantan Rzewnicki wrote: > On Tue, Oct 27, 2009 at 02:49:18PM -0700, Eric Kolotyluk wrote: >> Sorry for what seems like a real newbie question, but who actually sets >> the mount point? Is it the client/source, the icecast.xml file, or both? > > As I understand it, a source client has to specify a mount point when it > connects. > > If that mount point was already specified in the icecast server config, > then the associated mount options will be applied. > > If the client specified mount point was not previously known to icecast, > then a new mount point with the name given by the source client is > created. Dynamic allocation of mountpoint names is not done. When using a native icecast source client (edcast can be configured for that) then a mountpoint is supplied by the source client and icecast uses that to lookup the authentication details and any other mount settings. When using a shoutcast style source client, then it does not send a mountpoint so icecast assumes one based upon the incoming port (actually 2 sequential ports). 2.3.1 only allowed one of these clients to connect at any one time (and used the global shoutcast-mount setting and 2 listen-socket sections), but 2.3.2 allows for several as long as they are on different ports (shoutcast-mount in the listen-socket). eg 8000

/myfirststream

9000

/mysecondstream

The mount tags we ship are commented out in the examples they are just there to help in showing you want can be done. There does not need to be a section but if it's there then those settings (if present) are applied, a typical one used is karl. From pm at nowster.me.uk Wed Oct 28 00:27:33 2009 From: pm at nowster.me.uk (Paul Martin) Date: Wed, 28 Oct 2009 00:27:33 +0000 Subject: [Icecast] Icecast Digest, Vol 65, Issue 4 In-Reply-To: <935112.68899.qm@web58408.mail.re3.yahoo.com> References: <935112.68899.qm@web58408.mail.re3.yahoo.com> Message-ID: <20091028002733.GB26171@nowster.org.uk> On Tue, Oct 27, 2009 at 04:33:53PM -0700, Edgardo Alfonso Tapia del Valle wrote: > Amigos: | Friends: > Ser?a posible que sus comentarios, sugerenciaas, invitaciones, consultas, > opiniones, los pueda recibir en idioma espa?ol? | Is it possible that comments, suggestions, invitations, questions | and opinions may be received in Spanish language? > Atentamente: | In kindness We have people of many countries here. The digest you quoted had discussions between people from Germany, Norway, the Czech Republic, amongst others. I personally don't speak Spanish, but can understand simple French, German, Latin and Welsh. Others may have different language skills. I find Yahoo's "Babelfish" useful for rough translation. Google also provides a similar service. http://translate.google.com/ -- Paul Martin From abitar.com at gmail.com Wed Oct 28 01:18:40 2009 From: abitar.com at gmail.com (David Saunders) Date: Tue, 27 Oct 2009 21:18:40 -0400 Subject: [Icecast] Who sets the mount point? In-Reply-To: <4AE76ADE.8000706@sfu.ca> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> <4AE72262.1020303@xiph.org> <20091027171449.GJ3536@album.bayer.ipv6ia.org> <4AE76ADE.8000706@sfu.ca> Message-ID: <6f779c410910271818q468fb14aib8af3e0b0091ddb6@mail.gmail.com> This is what i found out in use with the icecast servers. Mounts Can be made by each of the following: 1> The icecast.xml file define a mount with a username/password for this mount. Since most our broadcaster using edcast to broadcast the username is set to source. 2> The use of the global source password can create a dynamic mount. But, the best way is to define it in the icecast.xml file by the mount. By using the method 2 to create a new mount that is not defined, will cause relaying not to happen. We current create a mount, and assign a password to the mount for each of out broadcasters. We also, defined mounts without passwords for in house streams using the source password. I cant say much for shoutcast mounts we don't use them. basicly, the source password can be used when ther mount has not been assigned a password in the icecast.xml file. So I guess the answer to your questions is, the icecast/xml is the preferred method of setting the mount and password :) david On Tue, Oct 27, 2009 at 5:49 PM, Eric Kolotyluk wrote: > Sorry for what seems like a real newbie question, but who actually sets > the mount point? Is it the client/source, the icecast.xml file, or both? > > I find the IceCast configuration documentation quite confusing as it > does not really explain mount points very well. If someone would take > the time to explain things to me I would volunteer to improve the > documentation. > > Case in point. I've been using IceCast for years, but never really > understood what I was doing. Recently I installed IceCast 2.3.1 on my > new computer. I have not configured anything - everything is the default > out of the box experience. As far as I can tell the default icecast.xml > file does not actually have any mount points defined, they are all > commented out. Am I correct? > > I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast > locked on to the first mount point I configured in ODDCAST, which > happened to be example-complex.ogg, and now I cannot seem to change it. > Is this how IceCast works, it takes whatever the client/source sends it > and then automatically creates a mount point? > > My problem now is my ODDCAST DSP seems to be locked into > example-complex.ogg as its 'destination' and won't release it even when > I change the mount point in the DSP Config settings. I would like to > change the mount point to something else, but I cannot figure out how. > Has the mount point "example-complex.ogg" been locked into my Winamp > configuration somewhere, or is something in the IceCast configuration > that is forcing this mount point? > > I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still > thinks it's configured to "example-complex.ogg" even though it has not > connected to IceCast yet. I suspect there is some magic winamp/oddcast > config file somewhere, but I am unable to find it (as Windows search > mechanism is hopelessly lame). > > Cheers, Eric > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > From eric at sfu.ca Wed Oct 28 04:33:51 2009 From: eric at sfu.ca (Eric Kolotyluk) Date: Tue, 27 Oct 2009 21:33:51 -0700 Subject: [Icecast] Who sets the mount point? In-Reply-To: <6f779c410910271818q468fb14aib8af3e0b0091ddb6@mail.gmail.com> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> <4AE72262.1020303@xiph.org> <20091027171449.GJ3536@album.bayer.ipv6ia.org> <4AE76ADE.8000706@sfu.ca> <6f779c410910271818q468fb14aib8af3e0b0091ddb6@mail.gmail.com> Message-ID: <4AE7C9AF.4030001@sfu.ca> OK, I solved my problem. I was using ODDCAST v2. I switched to edcast (ODDCAST v3) and was able to set the mountpoint to something different. I can change it in the edcast configuration and it automatically changes the mount-point in IceCast. Wha-Hoo! There is some incredibly valuable information in this thread that should be in the IceCast documentation on the "Icecast 2 - Basic Setup" page. It would also be nice if there were an official Icecast wiki somewhere so that people could document things as they figure them out. Thanks everyone for the tips. Cheers, Eric On 10/27/2009 6:18 PM, David Saunders wrote: > This is what i found out in use with the icecast servers. > > Mounts Can be made by each of the following: > > 1> The icecast.xml file define a mount with a username/password for > this mount. Since most our broadcaster using edcast to broadcast the > username is set to source. > > 2> The use of the global source password can create a dynamic mount. > > But, the best way is to define it in the icecast.xml file by the > mount. By using the method 2 to create a new mount that is not > defined, will cause relaying not to happen. > > We current create a mount, and assign a password to the mount for each > of out broadcasters. We also, defined mounts without passwords for in > house streams using the source password. > > I cant say much for shoutcast mounts we don't use them. > > basicly, the source password can be used when ther mount has not been > assigned a password in the icecast.xml file. > > So I guess the answer to your questions is, the icecast/xml is the > preferred method of setting the mount and password :) > > > > david > > On Tue, Oct 27, 2009 at 5:49 PM, Eric Kolotyluk wrote: > >> Sorry for what seems like a real newbie question, but who actually sets >> the mount point? Is it the client/source, the icecast.xml file, or both? >> >> I find the IceCast configuration documentation quite confusing as it >> does not really explain mount points very well. If someone would take >> the time to explain things to me I would volunteer to improve the >> documentation. >> >> Case in point. I've been using IceCast for years, but never really >> understood what I was doing. Recently I installed IceCast 2.3.1 on my >> new computer. I have not configured anything - everything is the default >> out of the box experience. As far as I can tell the default icecast.xml >> file does not actually have any mount points defined, they are all >> commented out. Am I correct? >> >> I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast >> locked on to the first mount point I configured in ODDCAST, which >> happened to be example-complex.ogg, and now I cannot seem to change it. >> Is this how IceCast works, it takes whatever the client/source sends it >> and then automatically creates a mount point? >> >> My problem now is my ODDCAST DSP seems to be locked into >> example-complex.ogg as its 'destination' and won't release it even when >> I change the mount point in the DSP Config settings. I would like to >> change the mount point to something else, but I cannot figure out how. >> Has the mount point "example-complex.ogg" been locked into my Winamp >> configuration somewhere, or is something in the IceCast configuration >> that is forcing this mount point? >> >> I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still >> thinks it's configured to "example-complex.ogg" even though it has not >> connected to IceCast yet. I suspect there is some magic winamp/oddcast >> config file somewhere, but I am unable to find it (as Windows search >> mechanism is hopelessly lame). >> >> Cheers, Eric >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast >> >> > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > From andreas.bergstrom at hiof.no Wed Oct 28 13:53:26 2009 From: andreas.bergstrom at hiof.no (=?iso-8859-1?Q?Andreas_Bergstr=F8m?=) Date: Wed, 28 Oct 2009 14:53:26 +0100 Subject: [Icecast] Vorbis still glitching on metadata update? In-Reply-To: <4AE72262.1020303@xiph.org> References: <9B992C70-CAAD-401F-8A8E-0457DBD0E601@hiof.no> <4AE72262.1020303@xiph.org> Message-ID: On 27. okt. 2009, at 17:40, Karl Heyes wrote: > inserts for ogg are different to mp3. It is generally better to get > the > source client to do that as it will be in sync with the content. > I see, thank you. I guess the challenge will be finding a system which allows insertion of metadata on the encoding side. >> Metadata is updated via the web admin interface from a script. >> >> Has anyone else encountered this or know a way to fix this issue? >> > > from here, ogg123 is ok (although a 128k buffer, not sure what the > prebuffer % is, seems to be low, try increasing those). I can look into increasing the burst-on-connect value. > mplayer is fine > but vlc keeps resetting itself in a major way on a new logical stream. > The format of the stream looks ok, I don't see any specific issue with > it. There is one other thing I can check but I'll have to get back to > you on that. OK, I will await that then while looking into inserting metadata at encoding time. Regards, -- Andreas Bergstr?m http://blog.andreasb.net From eric.a.labelle at gmail.com Fri Oct 30 03:42:17 2009 From: eric.a.labelle at gmail.com (Fu Kite (Eric Labelle)) Date: Thu, 29 Oct 2009 23:42:17 -0400 Subject: [Icecast] serving crossdomain.xml from icecast web-root Message-ID: Hi I'm trying to serve a flash app the crossdomain.xml file for a flash app from the web root of my icecast2 server but everytime my app requests the file it gets it but with the wrong mime type. After asking on irc I tried the following solution: /etc/mime.types ... to force it to use the main server mime-type definitions however it still served the file as application/octet-stream and was ignored by flash which ended up throwing a security sandbox exception... http://lists.xiph.org/pipermail/icecast/2009-April/011444.html this user (david saunders) somehow got it to work back in april so if david or anyone else can explain how they overcame this problem (or anyone else) i would be really grateful. Thanks -- Eric Labelle ________________________________ Dubearth Collective (Québec, Canada) - www.dubearth.com || myspace.com/dubearth -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlist at gulfbridge.net Fri Oct 30 05:48:55 2009 From: johnlist at gulfbridge.net (johnlist at gulfbridge.net) Date: Fri, 30 Oct 2009 01:48:55 -0400 (EDT) Subject: [Icecast] Using MPD as an Icecast source (hint: using jack helps) Message-ID: <59776.74.132.97.80.1256881735.squirrel@gulfbridge.net> I thought I should report this: (In my case at least) defining a "jack" output for mpd caused a "shout" output to become operational. I was trying to configure mpd with a "shout" output to feed my Icecast2 server, but with no luck. Giving up, I fell back to option 2: Feeding my mpd output to darkice using "jack" as an interface. As soon as I had defined the jack output in mpd.conf, the already-defined-but-not-working "shout" output started working! All I did was add the following to mpd.conf: audio_output { type "jack" name "my jack device" } I am using mpd 0.14.2 (Ubuntu 9.04). From dm8tbr at afthd.tu-darmstadt.de Fri Oct 30 07:11:14 2009 From: dm8tbr at afthd.tu-darmstadt.de (dm8tbr at afthd.tu-darmstadt.de) Date: Fri, 30 Oct 2009 08:11:14 +0100 Subject: [Icecast] Using MPD as an Icecast source (hint: using jack helps) In-Reply-To: <59776.74.132.97.80.1256881735.squirrel@gulfbridge.net> References: <59776.74.132.97.80.1256881735.squirrel@gulfbridge.net> Message-ID: <20091030071114.GE9119@dk0td.afthd.tu-darmstadt.de> On Fri, Oct 30, 2009 at 01:48:55AM -0400, johnlist at gulfbridge.net wrote: > I thought I should report this: (In my case at least) defining a "jack" > output for mpd caused a "shout" output to become operational. sounds like an regression to me. This bug appeared in mpd quite some time ago and was supposedly fixed. mpd doesn't have a good record in terms of icecast2 support. Last thing I've heard quite often was that streams generated by mpd and sent to an icecast2 server made listener clients stop on song change. still mpd is a very nice source client - once you get it working. Cheers Thomas