| View previous topic :: View next topic |
| Author |
Message |
cmodyssey
Joined: 28 Mar 2008 Posts: 63
|
Posted: Fri Mar 28, 2008 9:18 pm Post subject: Keep listeners connected between sources |
|
|
Hi,
I've not been playing with icecast for very long and I'm just trying to figure out if icecast can do this.
Say that source number 1 connects and start streaming to icecast.
Then listeners start listening to the stream, which works OK.
Then source number 1 disconnects from icecast and source number 2 connects to icecast.
What the listeners experience is just silence as soon as source number 1 disconnects and the audio from source number 2 does not come through.
The only way to get the listener to hear the audio, is to click on the "Click to Listen".
Is there any way to make sure that the listener does not have to do anything to listen to source number 2 without doing anything?
Even if a 2 hour mp3 is played (as source 2 may take a few seconds or a few hours to start streaming)
Any pointers would be greatly appreciated.
Thanks in advance
Here is a censored version of my current config file:
| Code: |
<!-- File location: /usr/local/etc/icecast.xml -->
<icecast>
<!-- Only define a <mount> section if you want to use advanced options,
like alternative usernames or passwords -->
<mount>
<mount-name>/live_mount</mount-name>
<password></password>
<max-listeners>10</max-listeners>
<!--<dump-file>/path/to/mp3filetosavestreamto.mp3</dump-file>-->
<!--<fallback-mount>fallback.mp3</fallback-mount>-->
<fallback-override>1</fallback-override>
</mount>
<limits>
<clients>10</clients>
<sources>2</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<!-- If enabled, this will provide a burst of data when a client
first connects, thereby significantly reducing the startup
time for listeners that do substantial buffering. However,
it also significantly increases latency between the source
client and listening client. For low-latency setups, you
might want to disable this. -->
<burst-on-connect>1</burst-on-connect>
<!-- same as burst-on-connect, but this allows for being more
specific on how much to burst. Most people won't need to
change from the default 64k. Applies to all mountpoints -->
<burst-size>65535</burst-size>
</limits>
<authentication>
<!-- Sources log in with username 'source' -->
<source-password>overwridden_by_mount_point</source-password>
<!-- Relays log in username 'relay' -->
<relay-password></relay-password>
<!-- Admin logs in with the username given below -->
<admin-user></admin-user>
<admin-password></admin-password>
</authentication>
<!-- Uncomment this if you want directory listings -->
<!--
<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
</directory>
<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://www.oddsock.org/cgi-bin/yp-cgi</yp-url>
</directory>
-->
<!-- This is the hostname other people will use to connect to your server.
It affects mainly the urls generated by Icecast for playlists and yp
listings. -->
<hostname>bitd_server</hostname>
<!-- You can use these two if you only want a single listener -->
<!--<port>8000</port> -->
<!--<bind-address>127.0.0.1</bind-address>-->
<!-- You may have multiple <listener> elements -->
<listen-socket>
<port>3389</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
</listen-socket>
<!--
<listen-socket>
<port>8001</port>
</listen-socket>
-->
<!--<master-server>127.0.0.1</master-server>-->
<!--<master-server-port>8001</master-server-port>-->
<!--<master-update-interval>120</master-update-interval>-->
<!--<master-password>hackme</master-password>-->
<!-- setting this makes all relays on-demand unless overridden, this is
useful for master relays which do not have <relay> definitions here.
The default is 0 -->
<!--<relays-on-demand>1</relays-on-demand>-->
<!--
<relay>
<server>127.0.0.1</server>
<port>8001</port>
<mount>/example.ogg</mount>
<local-mount>/different.ogg</local-mount>
<on-demand>0</on-demand>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
</relay>
-->
<fileserve>1</fileserve>
<!-- set the mountpoint for a shoutcast source to use, the default if not
specified is /stream but you can change it here if an alternative is
wanted or an extension is required
<shoutcast-mount>/live.nsv</shoutcast-mount>
-->
<paths>
<!-- basedir is only used if chroot is enabled -->
<basedir>/usr/local/share/icecast</basedir>
<!-- Note that if <chroot> is turned on below, these paths must both
be relative to the new root, not the original root -->
<logdir>/var/log/icecast</logdir>
<webroot>/usr/local/share/icecast/web</webroot>
<adminroot>/usr/local/share/icecast/admin</adminroot>
<!-- <pidfile>/usr/local/share/icecast/icecast.pid</pidfile> -->
<!-- Aliases: treat requests for 'source' path as being for 'dest' path
May be made specific to a port or bound address using the "port"
and "bind-address" attributes.
-->
<!--
<alias source="/foo" dest="/bar"/>
-->
<!-- Aliases: can also be used for simple redirections as well,
this example will redirect all requests for http://server:port/ to
the status page
-->
<alias source="/" dest="/status.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<!-- <playlistlog>playlist.log</playlistlog> -->
<loglevel>4</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
<logsize>10000</logsize> <!-- Max size of a logfile -->
<!-- If logarchive is enabled (1), then when logsize is reached
the logfile will be moved to [error|access|playlist].log.DATESTAMP,
otherwise it will be moved to [error|access|playlist].log.old.
Default is non-archive mode (i.e. overwrite)
-->
<!-- <logarchive>1</logarchive> -->
</logging>
<security>
<chroot>0</chroot>
<changeowner>
<user>bcast</user>
<group>bcast</group>
</changeowner>
</security>
</icecast>
|
|
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sat Mar 29, 2008 4:45 am Post subject: |
|
|
read the docs, you should find what you want with the fallback-mount and fallback-override settings. You can specify a file in webroot if you wish.
karl. |
|
| Back to top |
|
 |
cmodyssey
Joined: 28 Mar 2008 Posts: 63
|
Posted: Sat Mar 29, 2008 9:33 pm Post subject: Documentation |
|
|
Hi karlH,
Thanks for your reply.
If I can simplify my query and then explain why I'm not to sure about using the fallback-mount and fallback-override settings, as I've already used them and have not got what I wanted out of them.
So, for the simple query, please could you let me know which documentation will help me resolve the listener not hearing anything when source number 2 starts streaming to icecast.
For the more complex query, where fallback-mount and fallback-override work towards what I am looking for, I have seen a thread on this where this has been tried and I also experience the same thing myself.
What happens is I specify a 2 hour long mp3 as the file in webroot and when source 1 disconnects, the listener starts hearing the content of the mp3 file, which is great so far. The problem I have with these settings is that once source number 2 starts streaming to icecast, the listeners do not get to hear the audio from source number 2 until about 5 minutes later.
I have heard that this is something to do with the speed that the mp3 file gets 'streamed' into icecast, so I know there is an explanation for it. Is there a way of making icecast 'flush' any buffer it has from the file in webroot as soon as source number 2 connects, so that the listeners do not have to wait 5 minutes to hear the audio from source number 2?
Thanks again,
Richard. |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sun Mar 30, 2008 2:02 am Post subject: |
|
|
Your last paragraph describes the issue directly, unfortunately when you send an unregulated file as part of the stream then the listeners buffer (TCP and app buffer) will expand to the 5 mins of audio that you are experiencing. icecast cannot flush data that has already been sent. The only way to make it regulated at the moment is to fallback to a stream not a file, which would mean either running the fallback stream all the time or hook in some scripts to start/stop the fallback stream using the on-[dis]connect tags.
karl. |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2002 phpBB Group subRebel style by ktauber
|