tag:old.nabble.com,2006:forum-2880Nabble - Icecast2009-11-08T12:07:14ZIcecast, the project, is a collection of programs and libraries for streaming audio over the Internet. Icecast home is <a href="http://www.icecast.org/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26257406Re: Fwd: Re: Can't support more than one listener2009-11-08T12:07:14Z2009-11-08T12:07:14ZKarl HeyesOn 08/11/09 19:35, Eric Kolotyluk wrote:
<br><div class='shrinkable-quote'><br>> As far as I can tell, the access.log file shows no indication of
<br>> listener activity, at least I can see no correspondence of log lines
<br>> that match when the listeners appear in the error.log file. Is there a
<br>> way to increase the logging level in this file? Should I be able to see
<br>> listeners attaching in this file?
<br>>
<br>> In the error.log file I can see no indication of a two listeners
<br>> attempting to connect. I can see where listener-a connects, but there is
<br>> no indication of the listener-b attempting to connect. I can see
<br>> listener-a disconnect, and then I can see listener-b connect, but there
<br>> is no indication of listener-a trying to reconnect. It is possible that
<br>> after listener-a connects, Icecast is not event getting a connect
<br>> message from listener-b because something else is blocking it out
<br>> (Windows or the router)? Maybe I need to install a packet listener on my
<br>> system an watch the ethernet traffic?
</div><br>I would agree with that
<br><br>> Possible problems are
<br>>
<br>> 1. My router. But I think not because the same router supports multiple
<br>> listeners with my old computer, and both computers are connected to the
<br>> same router.
<br><br>very unlikely to be the router.
<br><br>> 2. My new computer is Windows 7 64-bit Ultimate RTM (with two ethernet
<br>> connections). My old computer is Windows XP (with one ethernet
<br>> connection). It would help if someone else could tell me if they have
<br>> Icecast working correctly (or not) on Windows 7.
<br><br>seeing that win7 is the new component in the chain, I would say this is
<br>very likely to be the cause. Probably down to the win7 firewall or TCP
<br>stack limiting connections, in theory a packet sniffer would still see
<br>the packets getting to the win7 network interface but would drop the
<br>connection immediately.
<br><br>karl.
<br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26257406&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26257113Fwd: Re: Can't support more than one listener2009-11-08T11:35:06Z2009-11-08T11:35:06ZEric Kolotyluk-2On 11/8/2009 7:37 AM, Karl Heyes wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On 08/11/09 01:24, Eric Kolotyluk wrote:
<br>>
<br>>> I'm running Icecast 3.2.1 on Windows 7 on my new computer and I've tried
<br>>> streaming with oddcast as well as shoutcast, but for some reason only
<br>>> one listener at a time can hear the stream.
<br>>>
<br>>> I'm running Icecast 2.3.1 on Windows XP on my old computer streaming
<br>>> with oddcast, and it supports multiple listeners just fine.
<br>>>
<br>>> Can anyone think of what is wrong with Icecast on my new computer?
<br>>>
<br>> What makes you think icecast is at fault in this case? are listeners
<br>> being rejected. Maybe you should look at both log files to see if
<br>> listeners are trying to connect, and if so why the second connection is
<br>> being dropped.
<br>>
<br>> karl.
<br>>
<br>>
<br>>
<br>> _______________________________________________
<br>> Icecast mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26257113&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br>> <a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br>>
</div>I don't know that Icecast is at fault, but I thought I would start with
</div>this maillist to see if anyone here can help. I've attached my Icecast
<br>files to this e-mail.
<br><br>As far as I can tell, the access.log file shows no indication of
<br>listener activity, at least I can see no correspondence of log lines
<br>that match when the listeners appear in the error.log file. Is there a
<br>way to increase the logging level in this file? Should I be able to see
<br>listeners attaching in this file?
<br><br>In the error.log file I can see no indication of a two listeners
<br>attempting to connect. I can see where listener-a connects, but there is
<br>no indication of the listener-b attempting to connect. I can see
<br>listener-a disconnect, and then I can see listener-b connect, but there
<br>is no indication of listener-a trying to reconnect. It is possible that
<br>after listener-a connects, Icecast is not event getting a connect
<br>message from listener-b because something else is blocking it out
<br>(Windows or the router)? Maybe I need to install a packet listener on my
<br>system an watch the ethernet traffic?
<br><br>Possible problems are
<br><br>1. My router. But I think not because the same router supports multiple
<br>listeners with my old computer, and both computers are connected to the
<br>same router.
<br><br>2. My new computer is Windows 7 64-bit Ultimate RTM (with two ethernet
<br>connections). My old computer is Windows XP (with one ethernet
<br>connection). It would help if someone else could tell me if they have
<br>Icecast working correctly (or not) on Windows 7.
<br><br>3. Icecast. I am running Icecast 2.3.1 on both computers (ignore what
<br>I said earlier about 3.2.1), and using the same icecast.xml file
<br>(except the ports are different). This is likely not the problem.
<br><br>Any more advice would be greatly appreciated.
<br><br>Cheers, Eric
<br><br><br><br /><icecast>
<br> <limits>
<br> <clients>100</clients>
<br> <sources>2</sources>
<br> <threadpool>5</threadpool>
<br> <queue-size>524288</queue-size>
<br> <client-timeout>30</client-timeout>
<br> <header-timeout>15</header-timeout>
<br> <source-timeout>10</source-timeout>
<br> <!-- If enabled, this will provide a burst of data when a client
<br> first connects, thereby significantly reducing the startup
<br> time for listeners that do substantial buffering. However,
<br> it also significantly increases latency between the source
<br> client and listening client. For low-latency setups, you
<br> might want to disable this. -->
<br> <burst-on-connect>1</burst-on-connect>
<br> <!-- same as burst-on-connect, but this allows for being more
<br> specific on how much to burst. Most people won't need to
<br> change from the default 64k. Applies to all mountpoints -->
<br> <burst-size>65535</burst-size>
<br> </limits>
<br><br> <authentication>
<br> <!-- Sources log in with username 'source' -->
<br> <source-password>stream2day</source-password>
<br> <!-- Relays log in username 'relay' -->
<br> <relay-password>stream2day</relay-password>
<br><br> <!-- Admin logs in with the username given below -->
<br> <admin-user>admin</admin-user>
<br> <admin-password>2b|~2b</admin-password>
<br> </authentication>
<br><br> <!-- Uncomment this if you want directory listings -->
<br> <!--
<br> <directory>
<br> <yp-url-timeout>15</yp-url-timeout>
<br> <yp-url><a href="http://dir.xiph.org/cgi-bin/yp-cgi" target="_top" rel="nofollow">http://dir.xiph.org/cgi-bin/yp-cgi</a></yp-url>
<br> </directory>
<br> <directory>
<br> <yp-url-timeout>15</yp-url-timeout>
<br> <yp-url><a href="http://www.oddsock.org/cgi-bin/yp-cgi" target="_top" rel="nofollow">http://www.oddsock.org/cgi-bin/yp-cgi</a></yp-url>
<br> </directory>
<br> -->
<br><br> <!-- This is the hostname other people will use to connect to your server.
<br> It affects mainly the urls generated by Icecast for playlists and yp
<br> listings. -->
<br> <hostname>192.168.0.103</hostname>
<br><br> <!-- You can use these two if you only want a single listener -->
<br> <!--<port>8000</port> -->
<br> <!--<bind-address>127.0.0.1</bind-address>-->
<br><br> <!-- You may have multiple <listener> elements -->
<br> <listen-socket>
<br> <port>8000</port>
<br> <!-- <bind-address>127.0.0.1</bind-address> -->
<br> </listen-socket>
<br> <!--
<br> <listen-socket>
<br> <port>8001</port>
<br> </listen-socket>
<br> -->
<br><br> <!--<master-server>127.0.0.1</master-server>-->
<br> <!--<master-server-port>8001</master-server-port>-->
<br> <!--<master-update-interval>120</master-update-interval>-->
<br> <!--<master-password>hackme</master-password>-->
<br><br> <!-- setting this makes all relays on-demand unless overridden, this is
<br> useful for master relays which do not have <relay> definitions here.
<br> The default is 0 -->
<br> <!--<relays-on-demand>1</relays-on-demand>-->
<br><br> <!--
<br> <relay>
<br> <server>127.0.0.1</server>
<br> <port>8001</port>
<br> <mount>/example.ogg</mount>
<br> <local-mount>/different.ogg</local-mount>
<br> <on-demand>0</on-demand>
<br><br> <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<br> </relay>
<br> -->
<br><br> <!-- Only define a <mount> section if you want to use advanced options,
<br> like alternative usernames or passwords
<br> <mount>
<br> <mount-name>/example-complex.ogg</mount-name>
<br><br> <username>othersource</username>
<br> <password>hackmemore</password>
<br><br> <max-listeners>1</max-listeners>
<br> <dump-file>/tmp/dump-example1.ogg</dump-file>
<br> <burst-size>65536</burst-size>
<br> <fallback-mount>/example2.ogg</fallback-mount>
<br> <fallback-override>1</fallback-override>
<br> <fallback-when-full>1</fallback-when-full>
<br> <intro>/example_intro.ogg</intro>
<br> <hidden>1</hidden>
<br> <no-yp>1</no-yp>
<br> <authentication type="htpasswd">
<br> <option name="filename" value="myauth"/>
<br> <option name="allow_duplicate_users" value="0"/>
<br> </authentication>
<br> <on-connect>/home/icecast/bin/stream-start</on-connect>
<br> <on-disconnect>/home/icecast/bin/stream-stop</on-disconnect>
<br> </mount>
<br><br> <mount>
<br> <mount-name>/auth_example.ogg</mount-name>
<br> <authentication type="url">
<br> <option name="mount_add" value="<a href="http://myauthserver.net/notify_mount.php" target="_top" rel="nofollow">http://myauthserver.net/notify_mount.php</a>"/>
<br> <option name="mount_remove" value="<a href="http://myauthserver.net/notify_mount.php" target="_top" rel="nofollow">http://myauthserver.net/notify_mount.php</a>"/>
<br> <option name="listener_add" value="<a href="http://myauthserver.net/notify_listener.php" target="_top" rel="nofollow">http://myauthserver.net/notify_listener.php</a>"/>
<br> <option name="listener_remove" value="<a href="http://myauthserver.net/notify_listener.php" target="_top" rel="nofollow">http://myauthserver.net/notify_listener.php</a>"/>
<br> </authentication>
<br> </mount>
<br><br> -->
<br><br> <fileserve>1</fileserve>
<br><br> <!-- set the mountpoint for a shoutcast source to use, the default if not
<br> specified is /stream but you can change it here if an alternative is
<br> wanted or an extension is required
<br> <shoutcast-mount>/live.nsv</shoutcast-mount>
<br> -->
<br><br> <paths>
<br> <!-- basedir is only used if chroot is enabled -->
<br> <basedir>./</basedir>
<br><br> <!-- Note that if <chroot> is turned on below, these paths must both
<br> be relative to the new root, not the original root -->
<br> <logdir>./logs</logdir>
<br> <webroot>./web</webroot>
<br> <adminroot>./admin</adminroot>
<br> <!-- <pidfile>./icecast.pid</pidfile> -->
<br><br> <!-- Aliases: treat requests for 'source' path as being for 'dest' path
<br> May be made specific to a port or bound address using the "port"
<br> and "bind-address" attributes.
<br> -->
<br> <!--
<br> <alias source="/foo" dest="/bar"/>
<br> -->
<br> <!-- Aliases: can also be used for simple redirections as well,
<br> this example will redirect all requests for <a href="http://server:port/" target="_top" rel="nofollow">http://server:port/</a> to
<br> the status page
<br> -->
<br> <alias source="/" dest="/status.xsl"/>
<br> </paths>
<br><br> <logging>
<br> <accesslog>access.log</accesslog>
<br> <errorlog>error.log</errorlog>
<br> <!-- <playlistlog>playlist.log</playlistlog> -->
<br> <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
<br> <logsize>10000</logsize> <!-- Max size of a logfile -->
<br> <!-- If logarchive is enabled (1), then when logsize is reached
<br> the logfile will be moved to [error|access|playlist].log.DATESTAMP,
<br> otherwise it will be moved to [error|access|playlist].log.old.
<br> Default is non-archive mode (i.e. overwrite)
<br> -->
<br> <!-- <logarchive>1</logarchive> -->
<br> </logging>
<br><br> <security>
<br> <chroot>0</chroot>
<br> <!--
<br> <changeowner>
<br> <user>nobody</user>
<br> <group>nogroup</group>
<br> </changeowner>
<br> -->
<br> </security>
<br></icecast>
<br><br><br />216.82.50.224 - - [08/Nov/2009:11:26:08 -0800] "GET /stream/7.html HTTP/1.0" 404 106 "-" "XML Getter (Mozilla Compatible)" 0
<br>24.83.23.157 - - [08/Nov/2009:11:27:04 -0800] "GET /quant.ogg HTTP/1.1" 200 413945 "-" "FMOD/3.74" 45
<br><br />[2009-11-08 11:26:00] INFO main/main.c Icecast 2.3.1 server started
<br>[2009-11-08 11:26:00] INFO yp/yp.c YP update thread started
<br>[2009-11-08 11:26:00] INFO auth/auth.c Authentication thread started
<br>[2009-11-08 11:26:08] INFO fserve/fserve.c checking for file /stream/7.html (./web/stream/7.html)
<br>[2009-11-08 11:26:08] WARN fserve/fserve.c req for file "./web/stream/7.html" No such file or directory
<br>[2009-11-08 11:26:10] INFO connection/connection.c Source logging in at mountpoint "/quant.ogg"
<br>[2009-11-08 11:26:11] INFO format-vorbis/format_vorbis.c seen initial vorbis header
<br>[2009-11-08 11:26:11] INFO format-vorbis/format_vorbis.c seen initial vorbis header
<br>[2009-11-08 11:26:19] INFO source/source.c listener count on /quant.ogg now 1
<br>[2009-11-08 11:27:04] INFO source/source.c listener count on /quant.ogg now 0
<br>[2009-11-08 11:27:06] INFO source/source.c listener count on /quant.ogg now 1
<br>[2009-11-08 11:29:49] INFO format-vorbis/format_vorbis.c seen initial vorbis header
<br>[2009-11-08 11:34:41] INFO format-vorbis/format_vorbis.c seen initial vorbis header
<br><br />_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26257113&i=1" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26254822Re: Can't support more than one listener2009-11-08T07:37:35Z2009-11-08T07:37:35ZKarl HeyesOn 08/11/09 01:24, Eric Kolotyluk wrote:
<br>> I'm running Icecast 3.2.1 on Windows 7 on my new computer and I've tried
<br>> streaming with oddcast as well as shoutcast, but for some reason only
<br>> one listener at a time can hear the stream.
<br>>
<br>> I'm running Icecast 2.3.1 on Windows XP on my old computer streaming
<br>> with oddcast, and it supports multiple listeners just fine.
<br>>
<br>> Can anyone think of what is wrong with Icecast on my new computer?
<br><br>What makes you think icecast is at fault in this case? are listeners
<br>being rejected. Maybe you should look at both log files to see if
<br>listeners are trying to connect, and if so why the second connection is
<br>being dropped.
<br><br>karl.
<br><br><br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26254822&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26251022Re: Can't support more than one listener2009-11-07T20:46:31Z2009-11-07T20:46:31ZEric Kolotyluk-2Does anyone else have Icecast running on Windows 7?
<br><br>Cheers, Eric
<br><br>On 11/7/2009 6:12 PM, Mike Murrell wrote:
<div class='shrinkable-quote'><br>> Windows 7 is a fixed version of Vista. The DRM issues among others are
<br>> still in place and will likely cause you issues.
<br>> Good luck
<br>> Mike
<br>>
<br>> -----Original Message-----
<br>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26251022&i=0" target="_top" rel="nofollow">icecast-bounces@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26251022&i=1" target="_top" rel="nofollow">icecast-bounces@...</a>] On Behalf
<br>> Of Eric Kolotyluk
<br>> Sent: Saturday, November 07, 2009 9:07 PM
<br>> To: John List
<br>> Cc: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26251022&i=2" target="_top" rel="nofollow">icecast@...</a>
<br>> Subject: Re: [Icecast] Can't support more than one listener
<br>>
<br>> On 11/7/2009 5:49 PM, John List wrote:
<br>>
<br>>> Eric Kolotyluk wrote:
<br>>>
<br>>>> I'm running Icecast 3.2.1 on Windows 7 on my new computer and I've
<br>>>> tried streaming with oddcast as well as shoutcast, but for some
<br>>>> reason only one listener at a time can hear the stream.
<br>>>>
<br>>>> I'm running Icecast 2.3.1 on Windows XP on my old computer streaming
<br>>>> with oddcast, and it supports multiple listeners just fine.
<br>>>>
<br>>>> Can anyone think of what is wrong with Icecast on my new computer?
<br>>>>
<br>>>> Cheers, Eric
<br>>>> _______________
<br>>>>
<br>>> My two cents' worth:
<br>>>
<br>>> Measure your upstream bandwidth to make sure you have adequate
<br>>> bandwidth to support multiple listeners.
<br>>>
<br>>> Monitor your icecast logs to see what happens when a second user tries
<br>>> to log on.
<br>>>
<br>>> John
<br>>>
<br>> I'm assuming I have enough upstream bandwidth because streaming to
<br>> multiple listeners on my old computer works fine. Both computers are on
<br>> the same network behind a router on a broadband connection.
<br>>
<br>> I'm not really sure what to look for in the logs. What log do I need to
<br>> look at, access or error? The error log is set to debug level and I can
<br>> see the listener count go up and down, to as high as 3.
<br>>
<br>> Cheers, Eric
<br>> _______________________________________________
<br>> Icecast mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26251022&i=3" target="_top" rel="nofollow">Icecast@...</a>
<br>> <a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br>>
<br>>
</div><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26251022&i=4" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26250428Re: Can't support more than one listener2009-11-07T18:07:27Z2009-11-07T18:07:27ZEric Kolotyluk-2On 11/7/2009 5:49 PM, John List wrote:
<div class='shrinkable-quote'><br>> Eric Kolotyluk wrote:
<br>>> I'm running Icecast 3.2.1 on Windows 7 on my new computer and I've
<br>>> tried streaming with oddcast as well as shoutcast, but for some
<br>>> reason only one listener at a time can hear the stream.
<br>>>
<br>>> I'm running Icecast 2.3.1 on Windows XP on my old computer streaming
<br>>> with oddcast, and it supports multiple listeners just fine.
<br>>>
<br>>> Can anyone think of what is wrong with Icecast on my new computer?
<br>>>
<br>>> Cheers, Eric
<br>>> _______________
<br>>
<br>> My two cents' worth:
<br>>
<br>> Measure your upstream bandwidth to make sure you have adequate
<br>> bandwidth to support multiple listeners.
<br>>
<br>> Monitor your icecast logs to see what happens when a second user tries
<br>> to log on.
<br>>
<br>> John
</div>I'm assuming I have enough upstream bandwidth because streaming to
<br>multiple listeners on my old computer works fine. Both computers are on
<br>the same network behind a router on a broadband connection.
<br><br>I'm not really sure what to look for in the logs. What log do I need to
<br>look at, access or error? The error log is set to debug level and I can
<br>see the listener count go up and down, to as high as 3.
<br><br>Cheers, Eric
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26250428&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26250336Re: Can't support more than one listener2009-11-07T17:49:20Z2009-11-07T17:49:20ZJohn HicksEric Kolotyluk wrote:
<div class='shrinkable-quote'><br>> I'm running Icecast 3.2.1 on Windows 7 on my new computer and I've tried
<br>> streaming with oddcast as well as shoutcast, but for some reason only
<br>> one listener at a time can hear the stream.
<br>>
<br>> I'm running Icecast 2.3.1 on Windows XP on my old computer streaming
<br>> with oddcast, and it supports multiple listeners just fine.
<br>>
<br>> Can anyone think of what is wrong with Icecast on my new computer?
<br>>
<br>> Cheers, Eric
<br>> _______________
</div><br>My two cents' worth:
<br><br>Measure your upstream bandwidth to make sure you have adequate bandwidth
<br>to support multiple listeners.
<br><br>Monitor your icecast logs to see what happens when a second user tries
<br>to log on.
<br><br>John
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26250336&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26250218Can't support more than one listener2009-11-07T17:24:42Z2009-11-07T17:24:42ZEric Kolotyluk-2I'm running Icecast 3.2.1 on Windows 7 on my new computer and I've tried
<br>streaming with oddcast as well as shoutcast, but for some reason only
<br>one listener at a time can hear the stream.
<br><br>I'm running Icecast 2.3.1 on Windows XP on my old computer streaming
<br>with oddcast, and it supports multiple listeners just fine.
<br><br>Can anyone think of what is wrong with Icecast on my new computer?
<br><br>Cheers, Eric
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26250218&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26248546Running the Omnia A/XE encoder and Icecast on the same machine2009-11-07T13:01:49Z2009-11-07T13:01:49ZMike MurrellCan someone tell me what IP address I should use to make this work? I have
<br>tried the normal 127.0.0.1 loopback and also the IP address of the machine
<br>with no luck. The A/XE software allows me to output to three types of
<br>servers. Shoutcast, Http, and Windows Media server. I have tried sending
<br>to all three even though I know using the shoutcast setting should work.
<br>You can see the software at
<br><a href="http://www.omniaaudio.com/products/coded-audio/omnia-axe.html" target="_top" rel="nofollow">http://www.omniaaudio.com/products/coded-audio/omnia-axe.html</a> Any help
<br>would be greatly appreciated.
<br>Thanks in advance
<br>Mike Murrell
<br>Chief Engineer
<br>WUOT
<br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26248546&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26125932Re: Using MPD as an Icecast source (hint: using jack helps)2009-10-30T00:11:14Z2009-10-30T00:11:14ZThomas B. Ruecker-2On Fri, Oct 30, 2009 at 01:48:55AM -0400, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26125932&i=0" target="_top" rel="nofollow">johnlist@...</a> wrote:
<br>> I thought I should report this: (In my case at least) defining a "jack"
<br>> output for mpd caused a "shout" output to become operational.
<br>sounds like an regression to me.
<br>This bug appeared in mpd quite some time ago and was supposedly fixed.
<br><br>mpd doesn't have a good record in terms of icecast2 support.
<br>Last thing I've heard quite often was that streams generated by mpd and sent
<br>to an icecast2 server made listener clients stop on song change.
<br><br>still mpd is a very nice source client - once you get it working.
<br><br>Cheers
<br><br>Thomas
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26125932&i=1" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26125359Using MPD as an Icecast source (hint: using jack helps)2009-10-29T22:48:55Z2009-10-29T22:48:55ZJohn HicksI thought I should report this: (In my case at least) defining a "jack"
<br>output for mpd caused a "shout" output to become operational.
<br><br>I was trying to configure mpd with a "shout" output to feed my Icecast2
<br>server, but with no luck.
<br><br>Giving up, I fell back to option 2: Feeding my mpd output to darkice using
<br>"jack" as an interface.
<br><br>As soon as I had defined the jack output in mpd.conf, the
<br>already-defined-but-not-working "shout" output started working!
<br><br>All I did was add the following to mpd.conf:
<br>audio_output {
<br> type "jack"
<br> name "my jack device"
<br>}
<br><br>I am using mpd 0.14.2 (Ubuntu 9.04).
<br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26125359&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26124531serving crossdomain.xml from icecast web-root2009-10-29T20:42:17Z2009-10-29T20:42:17ZFu Kite (Eric Labelle)Hi<br><br>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:<br>
<br><icecast><br><mime-types>/etc/mime.types</mime-types><br>...<br><br>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...<br>
<br><a href="http://lists.xiph.org/pipermail/icecast/2009-April/011444.html" target="_top" rel="nofollow">http://lists.xiph.org/pipermail/icecast/2009-April/011444.html</a><br><br>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.<br clear="all">
<br>Thanks<br>-- <br>Eric Labelle<br>________________________________<br>Dubearth Collective (Qu&eacute;bec, Canada) - <a href="http://www.dubearth.com" target="_top" rel="nofollow">www.dubearth.com</a> || <a href="http://myspace.com/dubearth" target="_top" rel="nofollow">myspace.com/dubearth</a><br>
<br><br>
<br />_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26124531&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26095028Re: Vorbis still glitching on metadata update?2009-10-28T06:53:26Z2009-10-28T06:53:26ZAndreas Bergstrøm<br>On 27. okt. 2009, at 17:40, Karl Heyes wrote:
<br><br>> inserts for ogg are different to mp3. It is generally better to get
<br>> the
<br>> source client to do that as it will be in sync with the content.
<br>>
<br><br>I see, thank you. I guess the challenge will be finding a system which
<br>allows insertion of metadata on the encoding side.
<br><br>>> Metadata is updated via the web admin interface from a script.
<br>>>
<br>>> Has anyone else encountered this or know a way to fix this issue?
<br>>>
<br>>
<br>> from here, ogg123 is ok (although a 128k buffer, not sure what the
<br>> prebuffer % is, seems to be low, try increasing those).
<br><br>I can look into increasing the burst-on-connect value.
<br><br>> mplayer is fine
<br>> but vlc keeps resetting itself in a major way on a new logical stream.
<br>> The format of the stream looks ok, I don't see any specific issue with
<br>> it. There is one other thing I can check but I'll have to get back to
<br>> you on that.
<br><br>OK, I will await that then while looking into inserting metadata at
<br>encoding time.
<br><br>Regards,
<br><br>--
<br>Andreas Bergstrøm
<br><a href="http://blog.andreasb.net" target="_top" rel="nofollow">http://blog.andreasb.net</a><br><br><br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26095028&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26089259Re: Who sets the mount point?2009-10-27T21:33:51Z2009-10-27T21:33:51ZEric Kolotyluk-2OK, I solved my problem. I was using ODDCAST v2. I switched to edcast
<br>(ODDCAST v3) and was able to set the mountpoint to something different.
<br>I can change it in the edcast configuration and it automatically changes
<br>the mount-point in IceCast. Wha-Hoo!
<br><br>There is some incredibly valuable information in this thread that should
<br>be in the IceCast documentation on the "Icecast 2 - Basic Setup" page.
<br><br>It would also be nice if there were an official Icecast wiki somewhere
<br>so that people could document things as they figure them out.
<br><br>Thanks everyone for the tips.
<br><br>Cheers, Eric
<br><br>On 10/27/2009 6:18 PM, David Saunders wrote:
<div class='shrinkable-quote'><br>> This is what i found out in use with the icecast servers.
<br>>
<br>> Mounts Can be made by each of the following:
<br>>
<br>> 1> The icecast.xml file define a mount with a username/password for
<br>> this mount. Since most our broadcaster using edcast to broadcast the
<br>> username is set to source.
<br>>
<br>> 2> The use of the global source password can create a dynamic mount.
<br>>
<br>> But, the best way is to define it in the icecast.xml file by the
<br>> mount. By using the method 2 to create a new mount that is not
<br>> defined, will cause relaying not to happen.
<br>>
<br>> We current create a mount, and assign a password to the mount for each
<br>> of out broadcasters. We also, defined mounts without passwords for in
<br>> house streams using the source password.
<br>>
<br>> I cant say much for shoutcast mounts we don't use them.
<br>>
<br>> basicly, the source password can be used when ther mount has not been
<br>> assigned a password in the icecast.xml file.
<br>>
<br>> So I guess the answer to your questions is, the icecast/xml is the
<br>> preferred method of setting the mount and password :)
<br>>
<br>>
<br>>
<br>> david
<br>>
<br>> On Tue, Oct 27, 2009 at 5:49 PM, Eric Kolotyluk<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26089259&i=0" target="_top" rel="nofollow">eric@...</a>> wrote:
<br>>
<br>>> Sorry for what seems like a real newbie question, but who actually sets
<br>>> the mount point? Is it the client/source, the icecast.xml file, or both?
<br>>>
<br>>> I find the IceCast configuration documentation quite confusing as it
<br>>> does not really explain mount points very well. If someone would take
<br>>> the time to explain things to me I would volunteer to improve the
<br>>> documentation.
<br>>>
<br>>> Case in point. I've been using IceCast for years, but never really
<br>>> understood what I was doing. Recently I installed IceCast 2.3.1 on my
<br>>> new computer. I have not configured anything - everything is the default
<br>>> out of the box experience. As far as I can tell the default icecast.xml
<br>>> file does not actually have any mount points defined, they are all
<br>>> commented out. Am I correct?
<br>>>
<br>>> I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast
<br>>> locked on to the first mount point I configured in ODDCAST, which
<br>>> happened to be example-complex.ogg, and now I cannot seem to change it.
<br>>> Is this how IceCast works, it takes whatever the client/source sends it
<br>>> and then automatically creates a mount point?
<br>>>
<br>>> My problem now is my ODDCAST DSP seems to be locked into
<br>>> example-complex.ogg as its 'destination' and won't release it even when
<br>>> I change the mount point in the DSP Config settings. I would like to
<br>>> change the mount point to something else, but I cannot figure out how.
<br>>> Has the mount point "example-complex.ogg" been locked into my Winamp
<br>>> configuration somewhere, or is something in the IceCast configuration
<br>>> that is forcing this mount point?
<br>>>
<br>>> I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still
<br>>> thinks it's configured to "example-complex.ogg" even though it has not
<br>>> connected to IceCast yet. I suspect there is some magic winamp/oddcast
<br>>> config file somewhere, but I am unable to find it (as Windows search
<br>>> mechanism is hopelessly lame).
<br>>>
<br>>> Cheers, Eric
<br>>> _______________________________________________
<br>>> Icecast mailing list
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26089259&i=1" target="_top" rel="nofollow">Icecast@...</a>
<br>>> <a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br>>>
<br>>>
<br>> _______________________________________________
<br>> Icecast mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26089259&i=2" target="_top" rel="nofollow">Icecast@...</a>
<br>> <a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br>>
</div><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26089259&i=3" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26087845Re: Who sets the mount point?2009-10-27T18:18:40Z2009-10-27T18:18:40Zabitar.comThis is what i found out in use with the icecast servers.
<br><br>Mounts Can be made by each of the following:
<br><br>1> The icecast.xml file define a mount with a username/password for
<br>this mount. Since most our broadcaster using edcast to broadcast the
<br>username is set to source.
<br><br>2> The use of the global source password can create a dynamic mount.
<br><br> But, the best way is to define it in the icecast.xml file by the
<br>mount. By using the method 2 to create a new mount that is not
<br>defined, will cause relaying not to happen.
<br><br>We current create a mount, and assign a password to the mount for each
<br>of out broadcasters. We also, defined mounts without passwords for in
<br>house streams using the source password.
<br><br>I cant say much for shoutcast mounts we don't use them.
<br><br>basicly, the source password can be used when ther mount has not been
<br>assigned a password in the icecast.xml file.
<br><br>So I guess the answer to your questions is, the icecast/xml is the
<br>preferred method of setting the mount and password :)
<br><br><br><br>david
<br><br>On Tue, Oct 27, 2009 at 5:49 PM, Eric Kolotyluk <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26087845&i=0" target="_top" rel="nofollow">eric@...</a>> wrote:
<div class='shrinkable-quote'><br>> Sorry for what seems like a real newbie question, but who actually sets
<br>> the mount point? Is it the client/source, the icecast.xml file, or both?
<br>>
<br>> I find the IceCast configuration documentation quite confusing as it
<br>> does not really explain mount points very well. If someone would take
<br>> the time to explain things to me I would volunteer to improve the
<br>> documentation.
<br>>
<br>> Case in point. I've been using IceCast for years, but never really
<br>> understood what I was doing. Recently I installed IceCast 2.3.1 on my
<br>> new computer. I have not configured anything - everything is the default
<br>> out of the box experience. As far as I can tell the default icecast.xml
<br>> file does not actually have any mount points defined, they are all
<br>> commented out. Am I correct?
<br>>
<br>> I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast
<br>> locked on to the first mount point I configured in ODDCAST, which
<br>> happened to be example-complex.ogg, and now I cannot seem to change it.
<br>> Is this how IceCast works, it takes whatever the client/source sends it
<br>> and then automatically creates a mount point?
<br>>
<br>> My problem now is my ODDCAST DSP seems to be locked into
<br>> example-complex.ogg as its 'destination' and won't release it even when
<br>> I change the mount point in the DSP Config settings. I would like to
<br>> change the mount point to something else, but I cannot figure out how.
<br>> Has the mount point "example-complex.ogg" been locked into my Winamp
<br>> configuration somewhere, or is something in the IceCast configuration
<br>> that is forcing this mount point?
<br>>
<br>> I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still
<br>> thinks it's configured to "example-complex.ogg" even though it has not
<br>> connected to IceCast yet. I suspect there is some magic winamp/oddcast
<br>> config file somewhere, but I am unable to find it (as Windows search
<br>> mechanism is hopelessly lame).
<br>>
<br>> Cheers, Eric
<br>> _______________________________________________
<br>> Icecast mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26087845&i=1" target="_top" rel="nofollow">Icecast@...</a>
<br>> <a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br>>
</div>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26087845&i=2" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26087624Re: Who sets the mount point?2009-10-27T17:49:57Z2009-10-27T17:49:57ZKarl HeyesOn 27/10/09 23:48, Eric Dantan Rzewnicki wrote:
<div class='shrinkable-quote'><br>> On Tue, Oct 27, 2009 at 02:49:18PM -0700, Eric Kolotyluk wrote:
<br>>> Sorry for what seems like a real newbie question, but who actually sets
<br>>> the mount point? Is it the client/source, the icecast.xml file, or both?
<br>>
<br>> As I understand it, a source client has to specify a mount point when it
<br>> connects.
<br>>
<br>> If that mount point was already specified in the icecast server config,
<br>> then the associated mount options will be applied.
<br>>
<br>> If the client specified mount point was not previously known to icecast,
<br>> then a new mount point with the name given by the source client is
<br>> created.
</div><br>Dynamic allocation of mountpoint names is not done.
<br><br>When using a native icecast source client (edcast can be configured for
<br>that) then a mountpoint is supplied by the source client and icecast
<br>uses that to lookup the authentication details and any other mount
<br>settings.
<br><br>When using a shoutcast style source client, then it does not send a
<br>mountpoint so icecast assumes one based upon the incoming port (actually
<br>2 sequential ports). 2.3.1 only allowed one of these clients to connect
<br>at any one time (and used the global shoutcast-mount setting and 2
<br>listen-socket sections), but 2.3.2 allows for several as long as they
<br>are on different ports (shoutcast-mount in the listen-socket). eg
<br><br><listen-socket>
<br> <port>8000</port>
<br> <shoutcast-mount>/myfirststream</shoutcast-mount>
<br></listen-socket>
<br><br><listen-socket>
<br> <port>9000</port>
<br> <shoutcast-mount>/mysecondstream</shoutcast-mount>
<br></listen-socket>
<br><br>The mount tags we ship are commented out in the examples
<br><!-- ignored --> they are just there to help in showing you want can be
<br>done. There does not need to be a <mount> section but if it's there
<br>then those settings (if present) are applied, a typical one used is
<br><max-listeners>
<br><br>karl.
<br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26087624&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26087776Re: Icecast Digest, Vol 65, Issue 42009-10-27T17:27:33Z2009-10-27T17:27:33ZPaul Martin-10On Tue, Oct 27, 2009 at 04:33:53PM -0700, Edgardo Alfonso Tapia del Valle wrote:
<br>> Amigos:
<br><br>| Friends:
<br><br>> Serìa posible que sus comentarios, sugerenciaas, invitaciones, consultas,
<br>> opiniones, los pueda recibir en idioma español?
<br><br>| Is it possible that comments, suggestions, invitations, questions
<br>| and opinions may be received in Spanish language?
<br><br>> Atentamente:
<br><br>| In kindness
<br><br>We have people of many countries here. The digest you quoted had discussions
<br>between people from Germany, Norway, the Czech Republic, amongst others.
<br><br>I personally don't speak Spanish, but can understand simple French, German,
<br>Latin and Welsh. Others may have different language skills.
<br><br>I find Yahoo's "Babelfish" useful for rough translation. Google also
<br>provides a similar service.
<br><br><a href="http://translate.google.com/" target="_top" rel="nofollow">http://translate.google.com/</a><br><br>--
<br>Paul Martin <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26087776&i=0" target="_top" rel="nofollow">pm@...</a>>
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26087776&i=1" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26087169Re: Who sets the mount point?2009-10-27T16:48:48Z2009-10-27T16:48:48ZEric Dantan Rzewnicki-2On Tue, Oct 27, 2009 at 02:49:18PM -0700, Eric Kolotyluk wrote:
<br>> Sorry for what seems like a real newbie question, but who actually sets
<br>> the mount point? Is it the client/source, the icecast.xml file, or both?
<br><br>As I understand it, a source client has to specify a mount point when it
<br>connects.
<br><br>If that mount point was already specified in the icecast server config,
<br>then the associated mount options will be applied.
<br><br>If the client specified mount point was not previously known to icecast,
<br>then a new mount point with the name given by the source client is
<br>created.
<br><br>-Eric Rz.
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26087169&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26086972Re: Icecast Digest, Vol 65, Issue 42009-10-27T16:33:53Z2009-10-27T16:33:53ZEdgardo Alfonso Tapia del ValleAmigos:
<br><br>Serìa posible que sus comentarios, sugerenciaas, invitaciones, consultas, opiniones, los pueda recibir en idioma español?
<br><br>Atentamente:
<br><br>Edgardo Tapia
<br><br>--- El mar 27-oct-09, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=0" target="_top" rel="nofollow">icecast-request@...</a> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=1" target="_top" rel="nofollow">icecast-request@...</a>> escribió:
<br><div class='shrinkable-quote'><br>> De: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=2" target="_top" rel="nofollow">icecast-request@...</a> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=3" target="_top" rel="nofollow">icecast-request@...</a>>
<br>> Asunto: Icecast Digest, Vol 65, Issue 4
<br>> A: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=4" target="_top" rel="nofollow">icecast@...</a>
<br>> Fecha: martes, 27 octubre, 2009, 4:00 pm
<br>> Send Icecast mailing list submissions
<br>> to
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=5" target="_top" rel="nofollow">icecast@...</a>
<br>>
<br>> To subscribe or unsubscribe via the World Wide Web, visit
<br>> <a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br>> or, via email, send a message with subject or body 'help'
<br>> to
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=6" target="_top" rel="nofollow">icecast-request@...</a>
<br>>
<br>> You can reach the person managing the list at
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=7" target="_top" rel="nofollow">icecast-owner@...</a>
<br>>
<br>> When replying, please edit your Subject line so it is more
<br>> specific
<br>> than "Re: Contents of Icecast digest..."
<br>>
<br>>
<br>> Today's Topics:
<br>>
<br>> 1. Vorbis still glitching on metadata
<br>> update? (Andreas Bergstr?m)
<br>> 2. Re: Vorbis still glitching on metadata
<br>> update? (Petr Pisar)
<br>> 3. Re: Vorbis still glitching on metadata
<br>> update? (Andreas Bergstr?m)
<br>> 4. Re: Vorbis still glitching on metadata
<br>> update? (Thomas B. Ruecker)
<br>> 5. Re: Vorbis still glitching on metadata
<br>> update? (Karl Heyes)
<br>> 6. Re: Vorbis still glitching on metadata
<br>> update? (Petr Pisar)
<br>>
<br>>
<br>> ----------------------------------------------------------------------
<br>>
<br>> Message: 1
<br>> Date: Tue, 27 Oct 2009 10:09:22 +0100
<br>> From: Andreas Bergstr?m <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=8" target="_top" rel="nofollow">andreas.bergstrom@...</a>>
<br>> Subject: [Icecast] Vorbis still glitching on metadata
<br>> update?
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=9" target="_top" rel="nofollow">icecast@...</a>
<br>> Message-ID: <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=10" target="_top" rel="nofollow">9B992C70-CAAD-401F-8A8E-0457DBD0E601@...</a>>
<br>> Content-Type: text/plain; charset=iso-8859-1;
<br>> format=flowed; delsp=yes
<br>>
<br>> Greetings,
<br>>
<br>> I am trying to track down a bug with intermittant glitching
<br>> in our
<br>> Vorbis streams.
<br>>
<br>> I am running Icecast 2.3.2 on Ubuntu 9.04.
<br>>
<br>> Several Vorbis clients seem to glitch on some (not all)
<br>> metadata
<br>> updates. As we update metadata 3 to 4 times a minute, this
<br>> is
<br>> something we are trying to fix, VLC gives the following
<br>> output on
<br>> metadata update:
<br>>
<br>> main warning: the mixer got a packet in the past (22371)
<br>> main warning: the mixer got a packet in the past (1038)
<br>> main warning: mixer start isn't output start (398)
<br>> ogg debug: end of a group of logical streams
<br>> ogg debug: found vorbis header
<br>> ogg debug: will reuse old stream to avoid glitch
<br>> ogg debug: beginning of a group of logical streams
<br>> main error: ES_OUT_RESET_PCR called
<br>> main warning: received buffer in the future
<br>> main debug: Buffering 0%
<br>> main debug: Buffering 0%
<br>> main debug: Buffering 19%
<br>> main debug: Buffering 40%
<br>> main debug: Buffering 63%
<br>> main debug: End of audio preroll
<br>> main debug: Buffering 84%
<br>> main debug: Stream buffering done (1274 ms in 144 ms)
<br>> main debug: Decoder buffering done in 0 ms
<br>>
<br>> For testing you can compare:
<br>>
<br>> <a href="http://radio.hiof.no/nrk-jazz-128" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128</a> (MP3 stream, no
<br>> glitching)
<br>> <a href="http://radio.hiof.no/nrk-jazz-128.ogg" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128.ogg</a><br>> (Vorbis stream, glitches)
<br>>
<br>> Metadata is updated via the web admin interface from a
<br>> script.
<br>>
<br>> Has anyone else encountered this or know a way to fix this
<br>> issue?
<br>>
<br>> Regards,
<br>>
<br>> --
<br>> Andreas Bergstr?m
<br>> ?stfold University College
<br>> Dept. of Computer Sciences
<br>> Tel: +47 69 21 53 71
<br>> <a href="http://media.hiof.no/" target="_top" rel="nofollow">http://media.hiof.no/</a><br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> ------------------------------
<br>>
<br>> Message: 2
<br>> Date: Tue, 27 Oct 2009 11:14:01 +0100
<br>> From: Petr Pisar <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=11" target="_top" rel="nofollow">petr.pisar@...</a>>
<br>> Subject: Re: [Icecast] Vorbis still glitching on metadata
<br>> update?
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=12" target="_top" rel="nofollow">icecast@...</a>
<br>> Message-ID: <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=13" target="_top" rel="nofollow">20091027101356.GG3536@...</a>>
<br>> Content-Type: text/plain; charset="utf-8"
<br>>
<br>> On Tue, Oct 27, 2009 at 10:09:22AM +0100, Andreas Bergstr?m
<br>> wrote:
<br>> >
<br>> > Several Vorbis clients seem to glitch on some (not
<br>> all) metadata
<br>> > updates. As we update metadata 3 to 4 times a minute,
<br>> this is
<br>> > something we are trying to fix, VLC gives the
<br>> following output on
<br>> > metadata update:
<br>> >
<br>> [?]
<br>> > <a href="http://radio.hiof.no/nrk-jazz-128.ogg" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128.ogg</a><br>> (Vorbis stream, glitches)
<br>> >
<br>> MPlayer plays very well, moc (music on console) too (but it
<br>> reports `Stream
<br>> error' on each meatadata update).
<br>>
<br>> Reference implementation ogg123 produces glitches. It says
<br>> ALSA underrun and
<br>> rebufferes the stream.
<br>>
<br>> All players tested with 128 kB buffer.
<br>>
<br>> BTW, I your IPv6 streams do not work because:
<br>>
<br>> $ ping6 -n radio.ipv6.hiof.no
<br>> PING
<br>> radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) 56
<br>> data bytes
<br>> From 2001:700:0:1003::2 icmp_seq=1 Destination unreachable:
<br>> Address unreachable
<br>>
<br>> -- Petr
<br>> -------------- next part --------------
<br>> A non-text attachment was scrubbed...
<br>> Name: not available
<br>> Type: application/pgp-signature
<br>> Size: 190 bytes
<br>> Desc: not available
<br>> Url : <a href="http://lists.xiph.org/pipermail/icecast/attachments/20091027/a6c2eabe/attachment-0001.pgp" target="_top" rel="nofollow">http://lists.xiph.org/pipermail/icecast/attachments/20091027/a6c2eabe/attachment-0001.pgp</a><br>>
<br>>
<br>> ------------------------------
<br>>
<br>> Message: 3
<br>> Date: Tue, 27 Oct 2009 12:11:19 +0100
<br>> From: Andreas Bergstr?m <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=14" target="_top" rel="nofollow">andreas.bergstrom@...</a>>
<br>> Subject: Re: [Icecast] Vorbis still glitching on metadata
<br>> update?
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=15" target="_top" rel="nofollow">icecast@...</a>
<br>> Message-ID: <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=16" target="_top" rel="nofollow">1AE9F48C-F0B7-42F9-9159-66196117678C@...</a>>
<br>> Content-Type: text/plain; charset=iso-8859-1;
<br>> format=flowed; delsp=yes
<br>>
<br>>
<br>> On 27. okt. 2009, at 11:14, Petr Pisar wrote:
<br>> > MPlayer plays very well, moc (music on console) too
<br>> (but it reports
<br>> `Stream
<br>> > error' on each meatadata update).
<br>>
<br>> OK, thank you.
<br>>
<br>> > Reference implementation ogg123 produces glitches. It
<br>> says ALSA
<br>> > underrun and
<br>> > rebufferes the stream.
<br>>
<br>> So could be clientside, could be serverside, time to dig
<br>> deeper, I
<br>> guess.
<br>>
<br>> > All players tested with 128 kB buffer.
<br>> >
<br>> > BTW, I your IPv6 streams do not work because:
<br>> >
<br>> > $ ping6 -n radio.ipv6.hiof.no
<br>> > PING
<br>> radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d)
<br>> 56
<br>> > data bytes
<br>> > From 2001:700:0:1003::2 icmp_seq=1 Destination
<br>> unreachable: Address
<br>> > unreachable
<br>>
<br>>
<br>> Ah thanks, found a configuration error, it _should_ work
<br>> now.
<br>>
<br>> Regards,
<br>>
<br>> --
<br>> Andreas Bergstr?m
<br>> ?stfold University College
<br>> Dept. of Computer Sciences
<br>> Tel: +47 69 21 53 71
<br>> <a href="http://media.hiof.no/" target="_top" rel="nofollow">http://media.hiof.no/</a><br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> ------------------------------
<br>>
<br>> Message: 4
<br>> Date: Tue, 27 Oct 2009 13:11:38 +0000
<br>> From: "Thomas B. Ruecker" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=17" target="_top" rel="nofollow">dm8tbr@...</a>>
<br>> Subject: Re: [Icecast] Vorbis still glitching on metadata
<br>> update?
<br>> To: Icecast <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=18" target="_top" rel="nofollow">Icecast@...</a>>
<br>> Message-ID: <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=19" target="_top" rel="nofollow">4AE6F18A.20101@...</a>>
<br>> Content-Type: text/plain; charset=ISO-8859-1;
<br>> format=flowed
<br>>
<br>> Hi,
<br>>
<br>> Andreas Bergstr?m schrieb:
<br>> > Metadata is updated via the web admin interface from a
<br>> script.
<br>> >
<br>>
<br>> sorry for stating the obvious:
<br>> Injecting the metadata directly within the source client is
<br>> not an
<br>> option for you?
<br>>
<br>>
<br>> Maybe Karl can say something about the metadata update?
<br>>
<br>> Cheers
<br>>
<br>> Thomas
<br>>
<br>>
<br>> ------------------------------
<br>>
<br>> Message: 5
<br>> Date: Tue, 27 Oct 2009 16:40:02 +0000
<br>> From: Karl Heyes <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=20" target="_top" rel="nofollow">karl@...</a>>
<br>> Subject: Re: [Icecast] Vorbis still glitching on metadata
<br>> update?
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=21" target="_top" rel="nofollow">icecast@...</a>
<br>> Message-ID: <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=22" target="_top" rel="nofollow">4AE72262.1020303@...</a>>
<br>> Content-Type: text/plain; charset=ISO-8859-1;
<br>> format=flowed
<br>>
<br>> On 27/10/09 09:09, Andreas Bergstr?m wrote:
<br>> > Greetings,
<br>> >
<br>> > I am trying to track down a bug with intermittant
<br>> glitching in our
<br>> > Vorbis streams.
<br>> >
<br>> > I am running Icecast 2.3.2 on Ubuntu 9.04.
<br>> >
<br>> > Several Vorbis clients seem to glitch on some (not
<br>> all) metadata
<br>> > updates. As we update metadata 3 to 4 times a minute,
<br>> this is
<br>> > something we are trying to fix, VLC gives the
<br>> following output on
<br>> > metadata update:
<br>>
<br>> > For testing you can compare:
<br>> >
<br>> > <a href="http://radio.hiof.no/nrk-jazz-128" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128</a> (MP3
<br>> stream, no glitching)
<br>> > <a href="http://radio.hiof.no/nrk-jazz-128.ogg" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128.ogg</a><br>> (Vorbis stream, glitches)
<br>>
<br>> inserts for ogg are different to mp3. It is generally
<br>> better to get the
<br>> source client to do that as it will be in sync with the
<br>> content.
<br>>
<br>> > Metadata is updated via the web admin interface from a
<br>> script.
<br>> >
<br>> > Has anyone else encountered this or know a way to fix
<br>> this issue?
<br>> >
<br>>
<br>> from here, ogg123 is ok (although a 128k buffer, not sure
<br>> what the
<br>> prebuffer % is, seems to be low, try increasing
<br>> those). mplayer is fine
<br>> but vlc keeps resetting itself in a major way on a new
<br>> logical stream.
<br>> The format of the stream looks ok, I don't see any specific
<br>> issue with
<br>> it. There is one other thing I can check but I'll have to
<br>> get back to
<br>> you on that.
<br>>
<br>> karl.
<br>>
<br>>
<br>>
<br>> ------------------------------
<br>>
<br>> Message: 6
<br>> Date: Tue, 27 Oct 2009 18:14:52 +0100
<br>> From: Petr Pisar <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=23" target="_top" rel="nofollow">petr.pisar@...</a>>
<br>> Subject: Re: [Icecast] Vorbis still glitching on metadata
<br>> update?
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=24" target="_top" rel="nofollow">icecast@...</a>
<br>> Message-ID: <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=25" target="_top" rel="nofollow">20091027171449.GJ3536@...</a>>
<br>> Content-Type: text/plain; charset="utf-8"
<br>>
<br>> On Tue, Oct 27, 2009 at 04:40:02PM +0000, Karl Heyes
<br>> wrote:
<br>> > On 27/10/09 09:09, Andreas Bergstr?m wrote:
<br>>
<br>> > > <a href="http://radio.hiof.no/nrk-jazz-128.ogg" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128.ogg</a><br>> (Vorbis stream, glitches)
<br>> >
<br>> > from here, ogg123 is ok (although a 128k buffer, not
<br>> sure what the
<br>> > prebuffer % is, seems to be low, try increasing
<br>> those).
<br>>
<br>> I check it out with bigger buffer (size 512 kB, prebuffer
<br>> 80 %) again
<br>> and it sounds perfectly now. Maybe mplayer has better TCP
<br>> tunning than
<br>> ogg123 because the buffer fill stays around 37--40 % but
<br>> ogg123 shows
<br>> decreasing fill periodically with 128kB buffer.
<br>>
<br>> -- Petr
<br>> -------------- next part --------------
<br>> A non-text attachment was scrubbed...
<br>> Name: not available
<br>> Type: application/pgp-signature
<br>> Size: 190 bytes
<br>> Desc: not available
<br>> Url : <a href="http://lists.xiph.org/pipermail/icecast/attachments/20091027/cced5677/attachment-0001.pgp" target="_top" rel="nofollow">http://lists.xiph.org/pipermail/icecast/attachments/20091027/cced5677/attachment-0001.pgp</a><br>>
<br>>
<br>> ------------------------------
<br>>
<br>> _______________________________________________
<br>> Icecast mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=26" target="_top" rel="nofollow">Icecast@...</a>
<br>> <a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br>>
<br>>
<br>> End of Icecast Digest, Vol 65, Issue 4
<br>> **************************************
<br>>
</div><br>__________________________________________________
<br>Correo Yahoo!
<br>Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
<br>Regístrate ya - <a href="http://correo.espanol.yahoo.com/" target="_top" rel="nofollow">http://correo.espanol.yahoo.com/</a>
<br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086972&i=27" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26086701Who sets the mount point?2009-10-27T14:49:18Z2009-10-27T14:49:18ZEric Kolotyluk-2Sorry for what seems like a real newbie question, but who actually sets
<br>the mount point? Is it the client/source, the icecast.xml file, or both?
<br><br>I find the IceCast configuration documentation quite confusing as it
<br>does not really explain mount points very well. If someone would take
<br>the time to explain things to me I would volunteer to improve the
<br>documentation.
<br><br>Case in point. I've been using IceCast for years, but never really
<br>understood what I was doing. Recently I installed IceCast 2.3.1 on my
<br>new computer. I have not configured anything - everything is the default
<br>out of the box experience. As far as I can tell the default icecast.xml
<br>file does not actually have any mount points defined, they are all
<br>commented out. Am I correct?
<br><br>I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast
<br>locked on to the first mount point I configured in ODDCAST, which
<br>happened to be example-complex.ogg, and now I cannot seem to change it.
<br>Is this how IceCast works, it takes whatever the client/source sends it
<br>and then automatically creates a mount point?
<br><br>My problem now is my ODDCAST DSP seems to be locked into
<br>example-complex.ogg as its 'destination' and won't release it even when
<br>I change the mount point in the DSP Config settings. I would like to
<br>change the mount point to something else, but I cannot figure out how.
<br>Has the mount point "example-complex.ogg" been locked into my Winamp
<br>configuration somewhere, or is something in the IceCast configuration
<br>that is forcing this mount point?
<br><br>I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still
<br>thinks it's configured to "example-complex.ogg" even though it has not
<br>connected to IceCast yet. I suspect there is some magic winamp/oddcast
<br>config file somewhere, but I am unable to find it (as Windows search
<br>mechanism is hopelessly lame).
<br><br>Cheers, Eric
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26086701&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26081596Re: Vorbis still glitching on metadata update?2009-10-27T10:14:52Z2009-10-27T10:14:52ZPetr PisarOn Tue, Oct 27, 2009 at 04:40:02PM +0000, Karl Heyes wrote:
<br>> On 27/10/09 09:09, Andreas Bergstrøm wrote:
<br><br>> > <a href="http://radio.hiof.no/nrk-jazz-128.ogg" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128.ogg</a> (Vorbis stream, glitches)
<br>>
<br>> from here, ogg123 is ok (although a 128k buffer, not sure what the
<br>> prebuffer % is, seems to be low, try increasing those).
<br><br>I check it out with bigger buffer (size 512 kB, prebuffer 80 %) again
<br>and it sounds perfectly now. Maybe mplayer has better TCP tunning than
<br>ogg123 because the buffer fill stays around 37--40 % but ogg123 shows
<br>decreasing fill periodically with 128kB buffer.
<br><br>-- Petr
<br><br /> <br />_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26081596&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>attachment0</strong> (197 bytes) <a href="http://old.nabble.com/attachment/26081596/0/attachment0" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26080987Re: Vorbis still glitching on metadata update?2009-10-27T09:40:02Z2009-10-27T09:40:02ZKarl HeyesOn 27/10/09 09:09, Andreas Bergstrøm wrote:
<div class='shrinkable-quote'><br>> Greetings,
<br>>
<br>> I am trying to track down a bug with intermittant glitching in our
<br>> Vorbis streams.
<br>>
<br>> I am running Icecast 2.3.2 on Ubuntu 9.04.
<br>>
<br>> Several Vorbis clients seem to glitch on some (not all) metadata
<br>> updates. As we update metadata 3 to 4 times a minute, this is
<br>> something we are trying to fix, VLC gives the following output on
<br>> metadata update:
</div><br>> For testing you can compare:
<br>>
<br>> <a href="http://radio.hiof.no/nrk-jazz-128" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128</a> (MP3 stream, no glitching)
<br>> <a href="http://radio.hiof.no/nrk-jazz-128.ogg" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128.ogg</a> (Vorbis stream, glitches)
<br><br>inserts for ogg are different to mp3. It is generally better to get the
<br>source client to do that as it will be in sync with the content.
<br><br>> Metadata is updated via the web admin interface from a script.
<br>>
<br>> Has anyone else encountered this or know a way to fix this issue?
<br>>
<br><br>from here, ogg123 is ok (although a 128k buffer, not sure what the
<br>prebuffer % is, seems to be low, try increasing those). mplayer is fine
<br>but vlc keeps resetting itself in a major way on a new logical stream.
<br>The format of the stream looks ok, I don't see any specific issue with
<br>it. There is one other thing I can check but I'll have to get back to
<br>you on that.
<br><br>karl.
<br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26080987&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26077480Re: Vorbis still glitching on metadata update?2009-10-27T06:11:38Z2009-10-27T06:11:38ZThomas B. Ruecker-2Hi,
<br><br>Andreas Bergstrøm schrieb:
<br>> Metadata is updated via the web admin interface from a script.
<br>>
<br><br>sorry for stating the obvious:
<br>Injecting the metadata directly within the source client is not an
<br>option for you?
<br><br><br>Maybe Karl can say something about the metadata update?
<br><br>Cheers
<br><br>Thomas
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26077480&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26075891Re: Vorbis still glitching on metadata update?2009-10-27T04:11:19Z2009-10-27T04:11:19ZAndreas Bergstrøm<br>On 27. okt. 2009, at 11:14, Petr Pisar wrote:
<br> > MPlayer plays very well, moc (music on console) too (but it reports
<br>`Stream
<br>> error' on each meatadata update).
<br><br>OK, thank you.
<br><br>> Reference implementation ogg123 produces glitches. It says ALSA
<br>> underrun and
<br>> rebufferes the stream.
<br><br>So could be clientside, could be serverside, time to dig deeper, I
<br>guess.
<br><br>> All players tested with 128 kB buffer.
<br>>
<br>> BTW, I your IPv6 streams do not work because:
<br>>
<br>> $ ping6 -n radio.ipv6.hiof.no
<br>> PING radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) 56
<br>> data bytes
<br>> From 2001:700:0:1003::2 icmp_seq=1 Destination unreachable: Address
<br>> unreachable
<br><br><br>Ah thanks, found a configuration error, it _should_ work now.
<br><br>Regards,
<br><br>--
<br>Andreas Bergstrøm
<br>Østfold University College
<br>Dept. of Computer Sciences
<br>Tel: +47 69 21 53 71
<br><a href="http://media.hiof.no/" target="_top" rel="nofollow">http://media.hiof.no/</a><br><br><br><br><br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26075891&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26075249Re: Vorbis still glitching on metadata update?2009-10-27T03:14:01Z2009-10-27T03:14:01ZPetr PisarOn Tue, Oct 27, 2009 at 10:09:22AM +0100, Andreas Bergstrøm wrote:
<br>>
<br>> Several Vorbis clients seem to glitch on some (not all) metadata
<br>> updates. As we update metadata 3 to 4 times a minute, this is
<br>> something we are trying to fix, VLC gives the following output on
<br>> metadata update:
<br>>
<br>[…]
<br>> <a href="http://radio.hiof.no/nrk-jazz-128.ogg" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128.ogg</a> (Vorbis stream, glitches)
<br>>
<br>MPlayer plays very well, moc (music on console) too (but it reports `Stream
<br>error' on each meatadata update).
<br><br>Reference implementation ogg123 produces glitches. It says ALSA underrun and
<br>rebufferes the stream.
<br><br>All players tested with 128 kB buffer.
<br><br>BTW, I your IPv6 streams do not work because:
<br><br>$ ping6 -n radio.ipv6.hiof.no
<br>PING radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) 56 data bytes
<br>From 2001:700:0:1003::2 icmp_seq=1 Destination unreachable: Address unreachable
<br><br>-- Petr
<br><br /> <br />_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26075249&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>attachment0</strong> (197 bytes) <a href="http://old.nabble.com/attachment/26075249/0/attachment0" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26074506Vorbis still glitching on metadata update?2009-10-27T02:09:22Z2009-10-27T02:09:22ZAndreas BergstrømGreetings,
<br><br>I am trying to track down a bug with intermittant glitching in our
<br>Vorbis streams.
<br><br>I am running Icecast 2.3.2 on Ubuntu 9.04.
<br><br>Several Vorbis clients seem to glitch on some (not all) metadata
<br>updates. As we update metadata 3 to 4 times a minute, this is
<br>something we are trying to fix, VLC gives the following output on
<br>metadata update:
<br><br>main warning: the mixer got a packet in the past (22371)
<br>main warning: the mixer got a packet in the past (1038)
<br>main warning: mixer start isn't output start (398)
<br>ogg debug: end of a group of logical streams
<br>ogg debug: found vorbis header
<br>ogg debug: will reuse old stream to avoid glitch
<br>ogg debug: beginning of a group of logical streams
<br>main error: ES_OUT_RESET_PCR called
<br>main warning: received buffer in the future
<br>main debug: Buffering 0%
<br>main debug: Buffering 0%
<br>main debug: Buffering 19%
<br>main debug: Buffering 40%
<br>main debug: Buffering 63%
<br>main debug: End of audio preroll
<br>main debug: Buffering 84%
<br>main debug: Stream buffering done (1274 ms in 144 ms)
<br>main debug: Decoder buffering done in 0 ms
<br><br>For testing you can compare:
<br><br><a href="http://radio.hiof.no/nrk-jazz-128" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128</a> (MP3 stream, no glitching)
<br><a href="http://radio.hiof.no/nrk-jazz-128.ogg" target="_top" rel="nofollow">http://radio.hiof.no/nrk-jazz-128.ogg</a> (Vorbis stream, glitches)
<br><br>Metadata is updated via the web admin interface from a script.
<br><br>Has anyone else encountered this or know a way to fix this issue?
<br><br>Regards,
<br><br>--
<br>Andreas Bergstrøm
<br>Østfold University College
<br>Dept. of Computer Sciences
<br>Tel: +47 69 21 53 71
<br><a href="http://media.hiof.no/" target="_top" rel="nofollow">http://media.hiof.no/</a><br><br><br><br><br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26074506&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-26022302Re: too many wakeups/sec?2009-10-23T00:55:04Z2009-10-23T00:55:04ZJussi Kukkonen-3...and one more test with kh17b. From 2.3.2 to kh17b the "wakeups/s"
<br>figure has come down 84% - 98% in my test cases. I have very little
<br>idea what Karl's been doing but from a user POV the results look very
<br>good.
<br><br>version wakeups/s when wakeups/s with
<br> idle (no mounts) 1 mount, 1 stream
<br>-------------------------------------------
<br>2.3.2 44 44
<br>trunk 13 13
<br>kh17 4 10
<br>kh17b 1 7
<br><br> - Jussi
<br>_______________________________________________
<br>Icecast-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26022302&i=0" target="_top" rel="nofollow">Icecast-dev@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast-dev" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast-dev</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---Dev-f496.html" embed="fixTarget[496]" target="_top" >Icecast - Dev</a></p>tag:old.nabble.com,2006:post-26005491Re: too many wakeups/sec?2009-10-22T00:46:43Z2009-10-22T00:46:43ZJussi Kukkonen-3Karl asked me to test with his kh17 branch and I did.
<br><br>It looks like this is the first time there is a difference between not
<br>doing anything and actually streaming (this could be a result of my
<br>very non-scientific testing but the numbers looked fairly constant).
<br><br>version wakeups/s when wakeups/s with
<br> idle (no mounts) 1 mount, 1 stream
<br>-------------------------------------------
<br>2.3.2 44 44
<br>trunk 13 13
<br>kh17 4 10
<br><br><br>This is a lot better for my use case case (mostly idle). Even the
<br>difference when streaming looks significant: the number of wakeups
<br>stays fairly stable over time so the 13 vs 10 difference should be a
<br>statistically significant one.
<br><br>- Jussi
<br>_______________________________________________
<br>Icecast-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26005491&i=0" target="_top" rel="nofollow">Icecast-dev@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast-dev" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast-dev</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---Dev-f496.html" embed="fixTarget[496]" target="_top" >Icecast - Dev</a></p>tag:old.nabble.com,2006:post-25998211Re: too many wakeups/sec?2009-10-21T11:55:01Z2009-10-21T11:55:01ZJussi Kukkonen-3On Wed, Oct 21, 2009 at 5:53 PM, Karl Heyes <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25998211&i=0" target="_top" rel="nofollow">karl@...</a>> wrote:
<br>>> I'm seeing quite a few wakeups/sec in icecast2 2.3.2 on Debian Testing.
<br>>> In fact, whether icecast is doing anything or not, powertop reports 44.3
<br>>> wakeups per second. This is pretty big number, on my laptop it means
<br>>> icecast alone is responsible for every third wakeup on idle.
<br>>
<br>> This will vary depending on what you have icecast doing but you should find
<br>> that the trunk code has less wakeups. The connection and stats parts are
<br>> not quite the same as the kh tree, although they have been changed, so you
<br>> should see an improvement.
<br><br>Thanks, Karl. Testing with trunk I can confirm this. Just as before it
<br>doesn't seem to make difference if icecast streams something or not,
<br>but there is a significant improvement compared to 2.3.2:
<br><br>2.3.2 44 wakeups/s
<br>trunk 13 wakeups/s
<br><br>13 wakeups is still not optimal when in reality my icecast usually has
<br>nothing to do (no mounts, no clients), but it is a lot better.
<br><br>Thanks for the good work,
<br> - Jussi
<br>_______________________________________________
<br>Icecast-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25998211&i=1" target="_top" rel="nofollow">Icecast-dev@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast-dev" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast-dev</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---Dev-f496.html" embed="fixTarget[496]" target="_top" >Icecast - Dev</a></p>tag:old.nabble.com,2006:post-25994126Re: too many wakeups/sec?2009-10-21T07:53:51Z2009-10-21T07:53:51ZKarl HeyesOn 21/10/09 10:56, Jussi Kukkonen wrote:
<div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> I would have filed this as a bug but bugs.xiph.org doesn't seem to work
<br>> (despite quite enthusiastically claiming to :)). So here goes:
<br>>
<br>> I'm seeing quite a few wakeups/sec in icecast2 2.3.2 on Debian Testing.
<br>> In fact, whether icecast is doing anything or not, powertop reports 44.3
<br>> wakeups per second. This is pretty big number, on my laptop it means
<br>> icecast alone is responsible for every third wakeup on idle.
<br>>
<br>> I have no time to start digging through the code right now, but please
<br>> post if you have a hunch where these wakeups are coming from. If I have
<br>> time later, I'll consult this thread.
</div><br>This will vary depending on what you have icecast doing but you should
<br>find that the trunk code has less wakeups. The connection and stats
<br>parts are not quite the same as the kh tree, although they have been
<br>changed, so you should see an improvement.
<br><br>karl.
<br><br><br>_______________________________________________
<br>Icecast-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25994126&i=0" target="_top" rel="nofollow">Icecast-dev@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast-dev" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast-dev</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---Dev-f496.html" embed="fixTarget[496]" target="_top" >Icecast - Dev</a></p>tag:old.nabble.com,2006:post-25989922too many wakeups/sec?2009-10-21T02:56:04Z2009-10-21T02:56:04ZJussi Kukkonen-3Hi,
<br><br>I would have filed this as a bug but bugs.xiph.org doesn't seem to work
<br>(despite quite enthusiastically claiming to :)). So here goes:
<br><br>I'm seeing quite a few wakeups/sec in icecast2 2.3.2 on Debian Testing.
<br>In fact, whether icecast is doing anything or not, powertop reports 44.3
<br>wakeups per second. This is pretty big number, on my laptop it means
<br>icecast alone is responsible for every third wakeup on idle.
<br><br>I have no time to start digging through the code right now, but please
<br>post if you have a hunch where these wakeups are coming from. If I have
<br>time later, I'll consult this thread.
<br><br> - Jussi
<br>_______________________________________________
<br>Icecast-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25989922&i=0" target="_top" rel="nofollow">Icecast-dev@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast-dev" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast-dev</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---Dev-f496.html" embed="fixTarget[496]" target="_top" >Icecast - Dev</a></p>tag:old.nabble.com,2006:post-25955408Re: Icecast Fedora9 migration problems2009-10-19T02:25:10Z2009-10-19T02:25:10ZMatrafuxtry to find out the real stream url. use curl
<br><br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Seann Clark wrote:</div>
<div class="quote-message shrinkable-quote">Ok, First I want to start off with this isn't the first icecast I have
<br>cloned, but it is the first where I have not only jumped Fedora release
<br>versions, but arch types as well (i386 - x86_64) and I am having strange
<br>problems. The Icecast versions are the same between the old and new servers.
<br><br>The biggest being is that the server binds to whatever port it feels
<br>like instead of the bind port specified. The rest of the issues I have
<br>with Icecast are minor (stats? What stats?) so here is the startup
<br>script and config I am using:
<br><br><br>Icecast 2.3.1:
<br>############Startup Script##########3
<br>#!/bin/sh
<br>#
<br># icecast This shell script takes care of starting and stopping
<br># the icecast multimedia streaming systen.
<br>#
<br># chkconfig: - 85 15
<br># description: icecast is a multimedia streaming daemon. It is used to \
<br># relay and offer multimedia streaming content.
<br># processname: icecast
<br># pidfile: /var/run/icecast/icecast.pid
<br># config: /etc/icecast.xml
<br><br># Source function library.
<br>. /etc/rc.d/init.d/functions
<br><br>[ -x /usr/bin/icecast ] || exit 0
<br><br># See how we were called.
<br>case "$1" in
<br> start)
<br> # Start daemon.
<br> echo -n $"Starting icecast streaming daemon: "
<br> daemon "/usr/bin/icecast -b -c /etc/icecast.xml > /dev/null"
<br> RETVAL=$?
<br> echo
<br> [ $RETVAL -eq 0 ] && touch /var/lock/subsys/icecast
<br> ;;
<br> stop)
<br> # Stop daemon.
<br> echo -n $"Shutting down icecast streaming daemon: "
<br> killproc icecast
<br> RETVAL=$?
<br> echo
<br> [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/icecast
<br> ;;
<br> status)
<br> status icecast
<br> RETVAL=$?
<br> ;;
<br> restart)
<br> $0 stop
<br> $0 start
<br> ;;
<br> reload)
<br> echo -n $"Reloading icecast: "
<br> killproc icecast -HUP
<br> RETVAL=$?
<br> echo
<br> ;;
<br> condrestart)
<br> [ -f /var/lock/subsys/icecast ] && restart || :
<br> ;;
<br> *)
<br> echo $"Usage: $0 {start|stop|status|restart|reload}"
<br> RETVAL=1
<br> ;;
<br>esac
<br><br>exit $RETVAL
<br><br><br><br>#################CONFIG#################
<br><icecast>
<br> <limits>
<br> <clients>100</clients>
<br> <sources>2</sources>
<br> <threadpool>5</threadpool>
<br> <queue-size>524288</queue-size>
<br> <client-timeout>30</client-timeout>
<br> <header-timeout>15</header-timeout>
<br> <source-timeout>10</source-timeout>
<br> <!-- same as burst-on-connect, but this allows for being more
<br> specific on how much to burst. Most people won't need to
<br> change from the default 64k. Applies to all mountpoints -->
<br> <burst-size>65535</burst-size>
<br> </limits>
<br><br> <authentication>
<br> <!-- Sources log in with username 'source' -->
<br> <source-password></source-password>
<br> <!-- Relays log in username 'relay' -->
<br> <relay-password></relay-password>
<br><br> <!-- Admin logs in with the username given below -->
<br> <admin-user></admin-user>
<br> <admin-password></admin-password>
<br> </authentication>
<br><br> <!-- Uncomment this if you want directory listings -->
<br> <!--
<br> <directory>
<br> <yp-url-timeout>15</yp-url-timeout>
<br> <yp-url><a href="http://dir.xiph.org/cgi-bin/yp-cgi" target="_top" rel="nofollow">http://dir.xiph.org/cgi-bin/yp-cgi</a></yp-url>
<br> </directory>
<br> <directory>
<br> <yp-url-timeout>15</yp-url-timeout>
<br> <yp-url><a href="http://www.oddsock.org/cgi-bin/yp-cgi" target="_top" rel="nofollow">http://www.oddsock.org/cgi-bin/yp-cgi</a></yp-url>
<br> </directory>
<br> -->
<br><br> <!-- This is the hostname other people will use to connect to your
<br>server.
<br> It affects mainly the urls generated by Icecast for playlists and yp
<br> listings. -->
<br> <hostname>hikari.tsukonokage.net</hostname>
<br><br> <!-- You can use these two if you only want a single listener -->
<br> <!--<port>8000</port> -->
<br> <!--<bind-address>127.0.0.1</bind-address>-->
<br><br> <!-- You may have multiple <listener> elements -->
<br> <listen-socket>
<br> <port>8000</port>
<br> <bind-address>192.168.10.5</bind-address>
<br> </listen-socket>
<br> <!--
<br> <listen-socket>
<br> <port>8001</port>
<br> </listen-socket>
<br> -->
<br><br> <master-server>192.168.10.5</master-server>
<br> <master-server-port>8001</master-server-port>
<br> <master-update-interval>120</master-update-interval>
<br> <master-password></master-password>
<br> <!--<master-relay-auth>1</master-relay-auth>-->
<br><br> <!-- setting this makes all relays on-demand unless overridden, this is
<br> useful for master relays which do not have <relay> definitions
<br>here.
<br> The default is 0 -->
<br> <relays-on-demand>0</relays-on-demand>
<br><br><br> <!-- Report <hostname> and this port to master server for redirecting
<br> clients to this slave -->
<br> <!--<master-redirect-port>8000</master-redirect-port>-->
<br><br> <!-- Relays. State connection information, and by default
<br> request inline metadata for mp3 streams if available.
<br> An on-demand relay will only retrieve the stream if
<br> there are listeners connected -->
<br> <!--
<br> <relay>
<br> <server>127.0.0.1</server>
<br> <port>8001</port>
<br> <mount>/example.ogg</mount>
<br> <local-mount>/different.ogg</local-mount>
<br> <on-demand>1</on-demand>
<br><br> <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<br> </relay>
<br> -->
<br><mount>
<br> <mount-name>/radio.ogg</mount-name>
<br> <username>haruhi</username>
<br> <password>123</password>
<br> <stream-name>tsukinokage.net's Audio Streams</stream-name>
<br> <stream-description>Music from
<br>www.tsukinokage.net</stream-description>
<br> <stream-url><a href="http://radio.tsukinokage.net" target="_top" rel="nofollow">http://radio.tsukinokage.net</a></stream-url>
<br> </mount>
<br><br> <!-- Only define a <mount> section if you want to use advanced options,
<br> like alternative usernames or passwords
<br> <mount>
<br> <mount-name>/example-complex.ogg</mount-name>
<br><br> <username>haruhi</username>
<br> <password></password>
<br><br> <max-listeners>100</max-listeners>
<br> <dump-file>/tmp/dump-example1.ogg</dump-file>
<br> <burst-size>65536</burst-size>
<br> <fallback-mount>/example2.ogg</fallback-mount>
<br> <fallback-override>1</fallback-override>
<br> <fallback-when-full>1</fallback-when-full>
<br> <intro>/path/to/stream-intro.ogg</intro>
<br> <hidden>1</hidden>
<br> <authentication type="htpasswd">
<br> <option name="filename" value="myauth"/>
<br> <option name="allow_duplicate_users" value="0"/>
<br> </authentication>
<br> <on-connect>/home/icecast/bin/stream-start</on-connect>
<br> <on-disconnect>/home/icecast/bin/stream-stop</on-disconnect>
<br> </mount>
<br> -->
<br> <!-- other auth possibilities include running a command
<br> to do the auth, mount, user and pass are passed via
<br> stdin to the program
<br> <mount>
<br> ....
<br> <authentication type="command">
<br> <option name="filename" value="auth_verify"/>
<br> </authentication>
<br><br> or
<br><br> for url auth, the add url needs to return a "icecast-auth-user:
<br>1" http
<br> header for a user to authenicate. Both urls are sent params via
<br>POST,
<br> add is sent id, mount, user, pass, ip, useragent
<br> remove is passed id, mount, user, pass, duration
<br><br><br> <authentication type="url">
<br><br> state username/password if url requires it
<br><br> <option name="username" value="admin"/>
<br> <option name="password" value="hackme"/>
<br> <option name="add"
<br>value="<a href="http://myauthserver.com/scripts/add_listener.php" target="_top" rel="nofollow">http://myauthserver.com/scripts/add_listener.php</a>"/>
<br> <option name="remove"
<br>value="<a href="http://myauthserver.com/scripts/del_listener.php" target="_top" rel="nofollow">http://myauthserver.com/scripts/del_listener.php</a>"/>
<br> </authentication>
<br> </mount -->
<br><br><stats_log>/var/log/icecast/stats.log</stats_log>
<br><statshtml_log>/var/www/html/icestat.html</statshtml_log>
<br><stats_time>30</stats_time>
<br> <fileserve>1</fileserve>
<br><br> <!-- set the mountpoint for a shoutcast source to use, the default
<br>if not
<br> specified is /stream but you can change it here if an
<br>alternative is
<br> wanted or an extension is required -->
<br> <shoutcast-mount>/listen.pls</shoutcast-mount>
<br><br><br> <paths>
<br> <!-- basedir is only used if chroot is enabled -->
<br> <basedir>/usr/share/icecast</basedir>
<br><br> <!-- Note that if <chroot> is turned on below, these paths must both
<br> be relative to the new root, not the original root -->
<br> <logdir>/var/log/icecast</logdir>
<br> <webroot>/usr/share/icecast/web</webroot>
<br> <adminroot>/usr/share/icecast/admin</adminroot>
<br> <pidfile>/var/run/icecast/icecast.pid</pidfile>
<br><br> <!-- Aliases: treat requests for 'source' path as being for
<br>'dest' path
<br> May be made specific to a port or bound address using the
<br>"port"
<br> and "bind-address" attributes.
<br> -->
<br> <!--
<br> <alias source="/foo" dest="/bar"/>
<br> -->
<br> <!-- Aliases: can also be used for simple redirections as well,
<br> this example will redirect all requests for
<br><a href="http://server:port/" target="_top" rel="nofollow">http://server:port/</a> to
<br> the status page
<br> -->
<br> <alias source="/" dest="/status.xsl"/>
<br> </paths>
<br><br> <logging>
<br> <accesslog>access.log</accesslog>
<br> <errorlog>error.log</errorlog>
<br> <playlistlog>playlist.log</playlistlog>
<br> <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
<br> </logging>
<br><br> <security>
<br> <chroot>0</chroot>
<br> <changeowner>
<br> <user>icecast</user>
<br> <group>icecast</group>
<br> </changeowner>
<br> </security>
<br></icecast>
<br><br><br><br><br><br>--
<br>Seann Clark
<br>Tsukinokage.net
<br>nombrandue@tsukinokage.net
<br><br>_______________________________________________
<br>Icecast mailing list
<br>Icecast@xiph.org
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a></div>
</div></blockquote>
<p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-25952037Re: icecast-2.3.2-kh17 versus icecast-2.3.22009-10-18T18:00:03Z2009-10-18T18:00:03ZKarl HeyesOn 18/10/09 14:52, Klaas Jan Wierenga wrote:
<div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> I've been using icecast-2.3.1 for some time now and it is really
<br>> working well for me, solid as a rock (no crashes) and running 100's of
<br>> streams and 1000's of listeners, but in order to support
<br>> authentication and have easier configuration I want to start using the
<br>> url authentication (esp. the stream_auth) and mount-name wildcards
<br>> that are supported by icecast-2.3.2-kh17.
<br>>
<br>> I am unsure about the stability of icecast-2.3.2-kh17 when using url
<br>> authentication for both stream and listener authentication. What are
<br>> the major differences between icecast-2.3.2 and the kh17 branch and
<br>> can you say anything about the stability of icecast-2.3.2-kh17 in
<br>> production use?
</div><br>kh17 hasn't been out for that long but I've had no problems reported
<br>about it. URL auth should be stable, there's been a fair amount of
<br>testing recently using URL auth because of the per-listener intro
<br>content feature recently added.
<br><br>The main difference between them is the threading structure. With
<br>2.3.2/trunk you have one thread per stream setup, which is fine for low
<br>numbers of streams but some are running many streams which means the
<br>loading on the server can be a problem. In the kh branch, the threads
<br>are limited by the <workers> setting, so you get a lot less switching
<br>between threads if you have say 100+ streams.
<br><br>There are other functional features that seem to be working well, like
<br>the wildcard mounts, average bitrate stats, bandwidth limiting per
<br>mount. Sending content from a fallback file is now throttled which was
<br>an issue under 2.3.2 for some people. Relays can have multiple server
<br>references (for when one fails). Some extra options are available for
<br>auth such as sending the listener to an alternative mountpoint on failure.
<br><br>master/slave setups are handled differently now. A slave relay uses an
<br>/admin link to retrieve the content. This means two things, that the
<br>slave connection can bypass the usual limits (max-listeners etc) and
<br>that an auth can be applied for the connection meaning that each slave
<br>can have their own user/pass.
<br><br>The stream auth support has already been merged into trunk although not
<br>for shoutcast style source clients. kh17 does allow a shoutcast source
<br>to use url auth.
<br><br><br>karl.
<br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952037&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-25948307informations in yp.xml on dir.xiph.org2009-10-18T09:45:54Z2009-10-18T09:45:54Zsegler_alexHello,
<br><br>I'm working on a plugin for rhythmbox that displays icecast streams with
<br>in infos from yp.xml
<br>My question is: why are not all informations available through the
<br>webpage on dir.xiph.org available in the yp.xml?
<br><br>Thanks in advance
<br>segler_alex
<br><br>--
<br>Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
<br>Siehe <a href="http://www.gnu.org/philosophy/no-word-attachments.de.html" target="_top" rel="nofollow">http://www.gnu.org/philosophy/no-word-attachments.de.html</a><br><br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25948307&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-25946868icecast-2.3.2-kh17 versus icecast-2.3.22009-10-18T06:52:36Z2009-10-18T06:52:36ZKlaas Jan Wierenga-2Hi,
<br><br>I've been using icecast-2.3.1 for some time now and it is really
<br>working well for me, solid as a rock (no crashes) and running 100's of
<br>streams and 1000's of listeners, but in order to support
<br>authentication and have easier configuration I want to start using the
<br>url authentication (esp. the stream_auth) and mount-name wildcards
<br>that are supported by icecast-2.3.2-kh17.
<br><br>I am unsure about the stability of icecast-2.3.2-kh17 when using url
<br>authentication for both stream and listener authentication. What are
<br>the major differences between icecast-2.3.2 and the kh17 branch and
<br>can you say anything about the stability of icecast-2.3.2-kh17 in
<br>production use?
<br><br>Any feedback is very much appreciated.
<br><br>Regards,
<br><br>Klaas Jan Wierenga
<br>_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25946868&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>tag:old.nabble.com,2006:post-25944154Re: How to get listed in dir.xiph.org? Solved: Use domain name without http:// for webhost2009-10-17T22:21:02Z2009-10-17T22:21:02ZJohn Hicks<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Karl Heyes wrote:
<blockquote cite="mid:4ADA8954.5060206@xiph.org" type="cite">On
18/10/09 00:43, John Hicks wrote:
<br>
<blockquote type="cite">I've been trying to tweak my icecast.xml file
to get listed in
<br>
xip.xiph.org, but am not making any progress.
<br>
I'm running icecast 2.3.1 and darkice 0.19
<br>
<br>
Here are what I think are the relvant parts of icecast.xml:
<br>
<directory>
<br>
<yp-url-timeout>15</yp-url-timeout>
<br>
<yp-url><a class="moz-txt-link-freetext" href="http://dir.xiph.org/cgi-bin/yp-cgi" target="_top" rel="nofollow">http://dir.xiph.org/cgi-bin/yp-cgi</a></yp-url>
<br>
</directory>
<br>
and
<br>
<mount>
<br>
<mount-name>/stream.ogg</mount-name>
<br>
<fallback-mount>/Silence.ogg</fallback-mount>
<br>
<fallback-override>1</fallback-override>
<br>
<hidden>0</hidden>
<br>
<no-yp>0</no-yp>
<br>
<public>1</public>
<br>
</mount>
<br>
</blockquote>
<br>
<blockquote type="cite">How often is the directory refreshed? (How
patient should I be?)
<br>
</blockquote>
<br>
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.
<br>
<br>
karl.
<br>
</blockquote>
<br>
Bingo! Following your suggestion, I checked my Icecast error log (duh)
and found:<br>
<tt>EROR yp/send_to_yp YP add on <a class="moz-txt-link-freetext" href="http://dir.xiph.org/cgi-bin/yp-cgi" target="_top" rel="nofollow">http://dir.xiph.org/cgi-bin/yp-cgi</a>
failed: Add refused. Reason: Illegal listen_url. Incorrect
<hostname>.<br>
</tt><font face="Helvetica, Arial, sans-serif"><br>
</font>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 <webhost> entry of my icecast.xml, I
finally stumbled on using the domain name only (without the <a class="moz-txt-link-freetext" href="http://" target="_top" rel="nofollow">http://</a>). <br>
<tt><webhost>mydomain.com</webhost></tt><br>
<br>
That did the trick!<br>
<br>
Thanks for the help, Karl (and Jiri and Jeff and Bryan)!<br>
<br>
John<br>
</body>
</html>
<br />_______________________________________________
<br>Icecast mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25944154&i=0" target="_top" rel="nofollow">Icecast@...</a>
<br><a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_top" rel="nofollow">http://lists.xiph.org/mailman/listinfo/icecast</a><br><p>From forum: <a href="http://old.nabble.com/Icecast---General-f497.html" embed="fixTarget[497]" target="_top" >Icecast - General</a></p>