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 

2.3.2-kh15b (win32) Fallback error?

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



Joined: 24 Nov 2007
Posts: 7

PostPosted: Sun Sep 13, 2009 3:59 am    Post subject: 2.3.2-kh15b (win32) Fallback error? Reply with quote

I don't know if this is a BUG or a Feature request
This is the issue.
I was using icecast 2.3-kh34a, in which I was using the following configuration.

<mount>
<mount-name>/live</mount-name>
<max-listeners>50</max-listeners>
<public>1</public>
<hidden>1</hidden>
<fallback-mount>/baliza</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
</mount>


<mount>
<mount-name>/baliza</mount-name>
<max-listeners>50</max-listeners>
<public>0</public>
<hidden>1</hidden>
<fallback-mount>/baliza.mp3</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
</mount>


This allowed me to move all the users to the mount /baliza when the source /live dropped, and it played directly from the server an mp3 archive with a beacon message until the source would come back and then move them to the /live feed.
The other day I updated to the 2.3.2-kh15b (win32) iceast version, to check the new updates and I found this is not working anymore.
Is this due to a bug? is there any other way I can do what I used to do before?

Thanks in advance.
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sun Sep 13, 2009 12:20 pm    Post subject: Reply with quote

This behaviour was described in kh10 when the fallback is a file. The problem with using a file is throttling the contents to an unknown bitrate, for some, it was increasing bandwidth usage considerably. With a file as a normal fallback the bitrate is determined from the originating stream but when the originating stream is missing then it cannot be determined.

It could be possible to place the listeners on the file (un-throttled) but not looped, or maybe specify a target in the xml but no one has provided feedback of that one. You can make /live a file or link to a file in webroot to get a once through playback working.

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



Joined: 24 Nov 2007
Posts: 7

PostPosted: Sun Sep 13, 2009 10:36 pm    Post subject: Reply with quote

You are correct, but my beacon is encoded at the same bitrate as the source stream and that configuration used work just fine though.

If you could please give me an example of what you are telling me in order to test I would greatly appreciate it.

Grettings.
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Mon Sep 14, 2009 12:17 am    Post subject: Reply with quote

You are assuming that icecast knows what bitrate the file is supposed to be sent at.

If you provide a 128k mp3 as a fallback to a stream, then we can regulate the sending rate based on what the stream was (average bitrate), but if there was no stream to start with then how do we know what bitrate to work to.

Previously the data was sent quickly so the listener would get a max'd out connection (a problem for relays or others on fast links) and usually wait for quite some time before any override would appear on playback.

The listeners now get a looped but throttled fallback file. If you request a file (eg mp3) from webroot then it is not throttled but it is also not repeated. You can create a link or copy to a file with the same name as the stream mountpoint, it won't repeat or override but can be useful to inform listeners.

The only thing I see that can help using the existing tags is by specifying a <limit-rate> mount setting. That could be used to throttle, if not specified then don't fallback. Another way is to define a list of files each with a bitrate limit, which could be useful in on-demand content cases.

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