View previous topic :: View next topic |
Author |
Message |
pzx5073
Joined: 24 Nov 2007 Posts: 7
|
Posted: Sun Sep 13, 2009 3:59 am Post subject: 2.3.2-kh15b (win32) Fallback error? |
|
|
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 |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sun Sep 13, 2009 12:20 pm Post subject: |
|
|
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 |
|
|
pzx5073
Joined: 24 Nov 2007 Posts: 7
|
Posted: Sun Sep 13, 2009 10:36 pm Post subject: |
|
|
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 |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Mon Sep 14, 2009 12:17 am Post subject: |
|
|
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 |
|
|
|