View previous topic :: View next topic |
Author |
Message |
gash
Joined: 25 Dec 2008 Posts: 5
|
Posted: Thu Dec 25, 2008 2:20 pm Post subject: Fallback still disconnects |
|
|
Hello everyone,
i have setup /MfT.ogg as a mainstream, and /playlist.ogg as a fallback (ices)
config:
Code: |
<mount>
<mount-name>/MfT.ogg</mount-name>
<fallback-mount>/playlist.ogg</fallback-mount>
<fallback-override>1</fallback-override>
<no-yp>1</no-yp>
</mount>
<mount>
<mount-name>/playlist.ogg</mount-name>
<max-listeners>250</max-listeners>
<hidden>1</hidden>
<no-yp>1</no-yp>
</mount>
|
problem:
the clients still get disconnected,
error log:
Code: |
[2008-12-25 15:13:19] WARN source/source_fallback_file unable to open file "/usr/local/share/icecast/web/playlist.ogg"
|
The playlist.ogg-mount is active and can be listened to
do i have an error in my config file or have i missed something? |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Thu Dec 25, 2008 2:33 pm Post subject: |
|
|
That message is not from listeners connecting. If you really have 2 streams on both those mountpoints actively streaming then there must something different in the formats which could cause the player to disconnect. I'm unable to verify the 2 streams from here as no address has been specified.
karl. |
|
Back to top |
|
|
gash
Joined: 25 Dec 2008 Posts: 5
|
Posted: Thu Dec 25, 2008 2:45 pm Post subject: |
|
|
http://www.escaflow.ws:8000/MfT.ogg <- the mainstream
http://www.escaflow.ws:8000/playlist.ogg <- the fallback playlist mount
config of the ices (maybe it can help too):
Code: |
<?xml version="1.0"?>
<ices>
<background>0</background>
<logpath>/var/www/web2/files/radio/log</logpath>
<logfile>ices.log</logfile>
<loglevel>4</loglevel>
<consolelog>0</consolelog>
<pidfile>./ices.pid</pidfile>
<stream>
<metadata>
<name>Playlist</name>
<genre>playlist</genre>
<description>Fallback playlist</description>
</metadata>
<input>
<module>playlist</module>
<param name="type">basic</param>
<param name="file">playlist.txt</param>
<param name="random">0</param>
<param name="restart-after-reread">0</param>
<param name="once">0</param>
</input>
<instance>
<hostname>78.47.85.32</hostname>
<port>8000</port>
<password>XXXXXXXXX</password>
<mount>/playlist.ogg</mount>
<reconnectdelay>2</reconnectdelay>
<reconnectattempts>5</reconnectattempts>
<maxqueuelength>80</maxqueuelength>
<encode>
<quality>0</quality>
<!-- <nominal-bitrate>64000</nominal-bitrate> -->
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
</instance>
</stream>
</ices>
|
|
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Thu Dec 25, 2008 2:54 pm Post subject: |
|
|
All I hear is a small file played then the bitrate drops to something really small then the file plays again. The format looks to be the same but if there are no messages indicating a stream reconnecting then it must be coming from the source clien, maybe that is having trouble with the input files?
karl. |
|
Back to top |
|
|
gash
Joined: 25 Dec 2008 Posts: 5
|
Posted: Thu Dec 25, 2008 2:57 pm Post subject: |
|
|
karlH wrote: |
All I hear is a small file played then the bitrate drops to something really small then the file plays again. The format looks to be the same but if there are no messages indicating a stream reconnecting then it must be coming from the source clien, maybe that is having trouble with the input files?
karl. |
well the playlist are 2 files,
one with the text and one with some silence to make sure ices repeats 'the same file' again
the fallback should usually only be used for a few seconds, when the sources(moderators) on the mainstream are changing |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Thu Dec 25, 2008 7:21 pm Post subject: |
|
|
well in that case, that is expected. I kept hearing a repeat of a jingle followed by silence then the jingle again. It didn't drop the stream
karl. |
|
Back to top |
|
|
gash
Joined: 25 Dec 2008 Posts: 5
|
Posted: Thu Dec 25, 2008 7:35 pm Post subject: |
|
|
isn't the reason behind a fallback, being there all the time?
|
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Thu Dec 25, 2008 8:24 pm Post subject: |
|
|
A fallback is there to allow listeners to move to and from it. At no point have you said why listeners are dropping, only that they are for some reason. I've tried it here and it didn't drop, so all I can say at the moment is that the icecast is not dropping my connection.
If icecast is dropping the listeners then it will report it in the error log, if you see nothing then it is most likely that the players have disconnected but there is nothing so far to indicate why those would do that.
karl. |
|
Back to top |
|
|
gash
Joined: 25 Dec 2008 Posts: 5
|
Posted: Thu Dec 25, 2008 9:32 pm Post subject: |
|
|
karlH wrote: |
A fallback is there to allow listeners to move to and from it. At no point have you said why listeners are dropping, only that they are for some reason. I've tried it here and it didn't drop, so all I can say at the moment is that the icecast is not dropping my connection.
If icecast is dropping the listeners then it will report it in the error log, if you see nothing then it is most likely that the players have disconnected but there is nothing so far to indicate why those would do that.
karl. |
well, the post was made about 2 hours before we started streaming to the public and we are still doing so, thats why i can't force the livestream (mft.ogg) to go offline~
we currently solved it the way that we move the listeners by hand to the playlist.ogg before we disconnect from the livestream and when the next one connected as source to the livestream, we move them back from the playlist.ogg to the mft.ogg mount |
|
Back to top |
|
|
als
Joined: 14 Oct 2008 Posts: 18
|
Posted: Mon Jan 26, 2009 9:56 am Post subject: |
|
|
It seems' that for some reasons Icecast thinks of your falback mount point is a file on it's disk....
As You already went online, you can add another fake Live stream with the same fallback for experiments. Then try to do some testing (all can be done without interrupting primary service):
1. Try to add explicit <source> and <password> fields to the fallback mountpoint definition.
2. Ensure, that fallback is connected before live (primary) stream.
Publish the result here. |
|
Back to top |
|
|
|