Icecast Streaming Media Server Forum Index Icecast Streaming Media Server
Icecast is a Xiph Foundation Project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Fallback stays on if stream buffers and dj reconnects....

 
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Bug Reports
View previous topic :: View next topic  
Author Message
Anonymous
Guest





PostPosted: Sun Apr 16, 2006 5:16 pm    Post subject: Fallback stays on if stream buffers and dj reconnects.... Reply with quote

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
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sun Apr 16, 2006 6:14 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Anonymous
Guest





PostPosted: Thu Apr 27, 2006 7:25 pm    Post subject: Reply with quote

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
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Thu Apr 27, 2006 9:28 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Guest






PostPosted: Thu Apr 27, 2006 11:21 pm    Post subject: Reply with quote

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.

Cool
Back to top
Anonymous
Guest





PostPosted: Fri May 05, 2006 6:00 pm    Post subject: Reply with quote

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
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Fri May 05, 2006 6:43 pm    Post subject: Reply with quote

The fallback-mount and fallback-override are the tags you need to define on the primary mountpoint.

karl
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Anonymous
Guest





PostPosted: Fri May 05, 2006 7:48 pm    Post subject: Reply with quote

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
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Fri May 05, 2006 7:56 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Anonymous
Guest





PostPosted: Fri May 05, 2006 8:04 pm    Post subject: Reply with quote

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
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Fri May 05, 2006 9:37 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Anonymous
Guest





PostPosted: Sat May 06, 2006 12:24 am    Post subject: Reply with quote

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
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sat May 06, 2006 1:33 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Bug Reports All times are GMT
Page 1 of 1

 
Jump to:  
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