View previous topic :: View next topic |
Author |
Message |
Anonymous Guest
|
Posted: Sun Apr 16, 2006 5:16 pm Post subject: Fallback stays on if stream buffers and dj reconnects.... |
|
|
If the DJ buffers out or loses the stream and the fallback picks it up, sometimes the DJ restarts the encoder but the fallback keeps playing until the DJ stops and restarts the encoder....
Is there a fix for this?
Also, Karl, I noticed PM's are disabled. Could you please repost the reporting URL? Instead of the old ones...
You can email me at tomwylderocks@yahoo.com...
Thank you so much for everyone's help.
peace. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sun Apr 16, 2006 6:14 pm Post subject: |
|
|
If the fallback override is set and is not moving the listeners when the mountpoint is re-established then that is a bug, but without the error log it's hard to comment further.
bug reports should be posted to trac.xiph.org (bugs.xiph.org)
karl. |
|
Back to top |
|
|
Anonymous Guest
|
Posted: Thu Apr 27, 2006 7:25 pm Post subject: |
|
|
Karl,
I'm getting the same errors and here's what my error log shows.
Code: |
[2006-04-27 16:23:38] WARN client/client.c source connection has died
[2006-04-27 16:23:38] INFO source/source.c End of Stream /ASW
[2006-04-27 16:23:38] INFO source/source.c Source "/ASW" exiting
[2006-04-27 16:23:38] INFO source/source.c passing 0 listeners to "/1000.mp3"
[2006-04-27 16:23:38] DBUG source/source.c clearing source "/ASW"
[2006-04-27 16:23:38] DBUG source/source.c freeing source "/ASW"
[2006-04-27 16:23:38] DBUG stats/stats.c update node listeners (0)
[2006-04-27 16:23:38] DBUG stats/stats.c delete source node /ASW
[2006-04-27 16:23:38] DBUG stats/stats.c update node clients (0)
[2006-04-27 16:23:38] DBUG stats/stats.c update node sources (1)
[2006-04-27 16:23:38] DBUG stats/stats.c new source stat /ASW
[2006-04-27 16:23:38] DBUG stats/stats.c new node listeners (0)
[2006-04-27 16:23:38] DBUG stats/stats.c new node max_listeners (unlimited)
[2006-04-27 16:23:43] DBUG stats/stats.c update node total_bytes_read (0)
[2006-04-27 16:23:43] DBUG stats/stats.c update node total_bytes_sent (254628)
[2006-04-27 16:23:48] DBUG stats/stats.c update node total_bytes_read (0)
[2006-04-27 16:23:48] DBUG stats/stats.c update node total_bytes_sent (254628)
[2006-04-27 16:23:53] DBUG stats/stats.c update node total_bytes_read (0)
[2006-04-27 16:23:53] DBUG stats/stats.c update node total_bytes_sent (254628) |
I've got fallback-override set and it will start playing the /ASW mount point, however I can still hear the 1000.mp3 playing in the background and from the log it doesn't look like it's actually switching people back to the /ASW mount when it sees it. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Thu Apr 27, 2006 9:28 pm Post subject: |
|
|
that above doesn't show the source reconnecting. so the fallback won't trigger there but later. Don't forget that at the point of switchover, there is still audio in the listeners queue.
karl. |
|
Back to top |
|
|
Guest
|
Posted: Thu Apr 27, 2006 11:21 pm Post subject: |
|
|
Smae thing, and I understand about audio from the fallback still being in listener's queue, but for instance, one of my DJ's went for three hours thinking he was encoding before finding out it was music still playing from the fallback (Ezstream) on air...
A workaround to this we've discovered is setting the source timeout to 20 seconds, thereby giving the DJ 10 extra seconds before the fallback grabs the stream, but also using the auto-reconnect in SAM3 to one second keeps the DJ on the air, even after a bad buffer incident. I realize not everyone uses SAM3 but for those that do stream using it...
Thank you.
|
|
Back to top |
|
|
Anonymous Guest
|
Posted: Fri May 05, 2006 6:00 pm Post subject: |
|
|
Karl I have a question/problem.
The setup we're looking for is that if the stream dies it falls back onto a mp3 of some background noise. Then when the stream comes back up it will switch back over to the original stream and keep going.
Can you definet your fallback-mount point as an mp3 and if so how can I get it to switch back to the original mount point when it comes back up? |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri May 05, 2006 6:43 pm Post subject: |
|
|
The fallback-mount and fallback-override are the tags you need to define on the primary mountpoint.
karl |
|
Back to top |
|
|
Anonymous Guest
|
Posted: Fri May 05, 2006 7:48 pm Post subject: |
|
|
I've tried that I've had
Code: |
<mount>
<mount-name>/ASW</mount-name>
<password>asw</password>
<hidden>0</hidden>
<no-yp>1</no-yp>
<fallback-mount>/1000.mp3</fallback-mount>
<fallback-override>1</fallback-override>
</mount> |
Where the 1000.mp3 is a short music file that can play.
The stream switches over to the mp3 file easily if I stop streaming to /ASW but whenever I restart the /ASW stream it doesn't switch back.
So now I'm confused how I can make it switch back to /ASW when it's active. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri May 05, 2006 7:56 pm Post subject: |
|
|
Every previous time this 'bug' has been mentioned, after investigating the override did kick in, but the listener completely forgot about the timing element, and didn't wait long enough for switchiver to kick in during playback.
Fallback to file does not do timing (requires parsing of the format) so the TCP buffer becomes full and at lower bitrates that can consume a fair amount of time. So to check, trigger the override and wait at the player for a few minutes, any changes will have to work their way through the TCP stack and the players buffer.
If this still a problem then the error log is best to check, as that will show if override it being handled.
karl. |
|
Back to top |
|
|
Anonymous Guest
|
Posted: Fri May 05, 2006 8:04 pm Post subject: |
|
|
Hmm well how long is a 'normal' amount of time to wait? Because what we're wanting to use it for it'd have to be an almost instant switchover so people didn't miss important details. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri May 05, 2006 9:37 pm Post subject: |
|
|
that is impossible to say, icecast itself will do an immediate switchover, but it's what has already been sent by icecast that causes the 'waiting'.
karl. |
|
Back to top |
|
|
Anonymous Guest
|
Posted: Sat May 06, 2006 12:24 am Post subject: |
|
|
Hmm because I tested it today and let it run for as long as it wanted and even after 5 minutes it still never switched over from the mp3 to the stream. I thought maybe my mp3 was too long so I cut it down to a 10 second clip and still the same thing. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sat May 06, 2006 1:33 am Post subject: |
|
|
The size of the clip will not matter, as that loops. It's the bitrate of the file vs your TCP send window and player buffer size. This is assuming that the override is applying which you haven't confirmed yet. I can keep suggesting this over and over again, but you really need to look at your error log (level 4) to see what is actually happening.
karl. |
|
Back to top |
|
|
|