Comments (5)
Sorry, github's markup destroyed my examples and patch (my first attempt to use github at all). Here I fix it:
Let's discuss following setup. We have first mount with max-listeners limited:
<mount-name>/nashe-192</mount-name>
<max-listeners>1</max-listeners>
<fallback-mount>/nashe-128.mp3</fallback-mount>
<fallback-when-full>1</fallback-when-full>
And we have fallback mount:
<mount-name>/nashe-128.mp3</mount-name>
<max-listeners>5700</max-listeners>
<fallback-mount>/nashe-64.mp3</fallback-mount>
<fallback-when-full>1</fallback-when-full>
When first mount is full, function source.c/source_add_listener() tries to find fallback mount for client, it founds it, updates "mount" string and continues with loop but forgets to update "minfo" structure.
For second loop iteration, if fallback mount is full too, it does not update "minfo" again, so loop would be endless without built-in loop breaker (10 iteration max) but this leads us to 403 error being sent to the user instead of serving it with next fallback.
Next, while checking for "max-listeners" limit this loop always compares current listeners count with original mount's limit instead of limit for fallback. So, in our case current listeners count is always compared with 1. This behavour differs from icecast-2.3.3 branch, is unexpected and undesirable. It often leads to non-working fallback when first mount has low limit.
The following patch fixes both problem for us and makes us allowed to use "internal mount redirects" like described above.
from icecast-kh.
--- src/source.c.orig 2013-04-02 21:16:12.000000000 +0400 +++ src/source.c 2013-04-02 22:20:47.000000000 +0400 @@ -2022,7 +2022,7 @@ if (mountinfo->max_listeners == -1) break; — if (source->listeners < (unsigned long)mountinfo->max_listeners) + if (source->listeners < (unsigned long)minfo->max_listeners) break; INFO1 ("max listener count reached on %s", source->mount); } @@ -2031,6 +2031,7 @@ { thread_rwlock_unlock (&source->lock); mount = minfo->fallback_mount; + minfo = config_find_mount (config_get_config_unlocked(), mount); INFO1 ("stream full trying %s", mount); loop--; continue;
from icecast-kh.
The example you state is a really bad example, you should always fall back or override to a stream/file with the same properties, a 192k stream is certainly not the same as 64k or 128k. Remember the fallback is primarily for moving listeners after the stream dies, not for mount selection at the beginning. URL auth could be used to allow a selection on the initial mountpoint and use the Mountpoint: header to move the rest to alternative mounts.
As for the code, the minfo is there for identifying the fallback mount if/when cascading, all other tests, like the authentication beforehand is against the originating requested mount. While the above change may be suitable for your set up, it is not generally and would need more work to allow for a completely backward compatible option to 2.3.x, probably involving a third variable that can be either depending on whether it's 2.3 compatible or not.
karl.
from icecast-kh.
I understand and accept your criticism on bitrates. Let's assume we have /source1-128, /fallback1-128 and /fallback2-128 (all 128Kbps) instead of /nashe-192, /nashe-128.mp3 and /nashe-64. You see, bitrate is irrelevant to the problem I want to discuss.
The problem is 1) effectively endless loop in source_add_listener() that never gets to evaluation of /fallback2-128 and evaluates /fallback1-128 again and again until loop breaker hits zero value and 2) 403 error code returned to the user.
Now I see that correct patch should be more complex due to authorization problem you've mentioned (we run only public streams). Nevertheless, I still think that described configuration should not be interpreted as source of 403 errors. In 2.3.3 it has sensible interpretation and there is no reason for 2.3.3-kh branch to be incapable of dealing with it.
from icecast-kh.
I am not entirely convince of your view that it's the only sensible interpretation, it's a valid one but not the only one. I suspect it's because of the view people have of a fallback, ie a fallback not supposed to be a main streaming point that others would use directly, after all, the listeners are not isolated when they fallback from others who connect directly.
If a fallback would become a hidden temporary stream which is a kind of relay, so that the listeners are isolated then matching the fallback mount details would be silly. There has been many cases where people want listeners isolated from the fallback, which is a common issue when people use a common fallback for many streams.
- The endless loop you mentioned has a limit of 10 and the source changes each time, remember it's matching the requested mount against each source details.
- The 403 will only occur if each source fails to match the criteria in the mountpoint requested, it's hardly a confusing interpretation.
It sounds like what you have is a difference in policy but I am unsure of what your goal is at the moment with regard to the streams you have and when you do and don't want to fallback. My initial guess was that you were doing some sort of first come, first served with 192k and 128k for the rest type of arrangement but I like to determine the direction of the code based on what people like to end up with.
karl.
from icecast-kh.
Related Issues (20)
- Multiple Master-Server for Relays (Aggregating Mounts) HOT 1
- Song metadata appearing incorrectly in directories
- /admin/listclients with URL authentication returns 403 Forbidden Mountpoint in use
- How to migrate to a previous version?
- A small hang in VLC when updating OGG/vorbis stream metadata.
- Server stops
- Icecast 2.4.0-kh22 -IPv6 addresses not shown on listmounts.xsl HOT 1
- kh22 Icecast crashes HOT 7
- Server: header does not honour server-id HOT 1
- Infinite redirect with Safari and very long URLs since kh21.7
- now-playing info in icecast > kh17 broken on iOS devices HOT 3
- KH22: Choppy playback on iOS 17 HOT 4
- What is the command I use for an http request to reload the icecast, without having to take it down? HOT 2
- socket leak with local nginx proxy used by listener_add
- kh22 (rev ea3554b) crashes (segfault) when serving XSL files protected using htpasswd authentication. HOT 2
- kh22 (rev ea3554b) unexpected error messages using htpasswd auth on mount points
- KH22 (KH >= 21.7) Reverse Proxying Broken HOT 3
- I can't accept https stream, what am I doing wrong
- Characters in Now playing
- burst of static after preroll (formats match)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from icecast-kh.