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 

New Server IC 2.3.4 v. KH Branch

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



Joined: 14 Nov 2009
Posts: 32

PostPosted: Fri Aug 23, 2013 9:18 pm    Post subject: New Server IC 2.3.4 v. KH Branch Reply with quote

Is there a good link that outlines the differences of features of the main IC 2.3.4 version v. the currnet KH branch?

I am moving servers and they will be putting on the version I decide on, but I would like to get more info main v. KH....I though I had a link that outlined this, but doesn't seem to be found right now.

So a good link to compare and contrast? Or have the versions caught up to each other ? ? ?

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


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sat Aug 24, 2013 12:35 pm    Post subject: Reply with quote

I could do with going through the list really, as I generally update it rarely.

The key things for people seem to be

performance at large scale. The worker thread structure seems to be working nicely for that. So instead of a thread per source, you have N workers that process clients. The 2 extreme cases that benefit at he most are 1 stream with all listeners on a multi CPU box and 100s-1000s streams.

FLV wrapping for flash playback without memory leaks. This also required frame alignment so works better if switching streams like with fallback. The FLV wrapping is per listener request so configuration changes were not required.

There are other features some are not as popular but important for some

relays can be multi-hosted, ie if a failure occurs on one another is tried, creating a cascade effect for relay retries.

wildcard mounts can be defined, so settings can be applied on a range of matching streams, typically auth, but with a recent update (using ${mount}) things like fallback and intro can work well for that.

auth has more features, like accepting intro content from the auth server on listener_add. auth can again scale better for cases with many connecting at the same time. stream_auth option (for authenticating source clients) is now merged into trunk. A Location: response header to listener_add will trigger a 302 response to the listener, or a Mountpoint: response header to send to another mountpoint on the server.

shoutcast-mount can be part of a listen-socket block which means that multiple shoutcast source clients can connect at the same time. Means that 2 ports for each one is still used but secondary block is not defined as it is already created for you.

there are some smaller behavioural changes that are different.

fallback to file is now speed regulated to some determined bitrate. This bitrate is either determined from the source stream incoming rate, from the <limit-rate> setting or kb value in the name of the file eg /fallback[64k].mp3. If all those are missing then a 404 is returned even if the file is present.

more settings can be altered over reload, like listen sockets. privileged ports are not closed as they typically require root rights which have been dropped at that point.

xml processing is better handled, things like 64k can be used not just 65536. Booleans settings can take on/off, true/false as well as 0/non-zero.

While the xml can be different to trunk like in the case of a cascading relay, it does accept the commonly used 2.3.2 format. There are other settings I haven't mentioned yet like max-bandwidth but I've not had that much feedback on that

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



Joined: 14 Nov 2009
Posts: 32

PostPosted: Mon Sep 02, 2013 8:42 pm    Post subject: Reply with quote

karlH wrote:
I could do with going through the list really, as I generally update it rarely

fallback to file is now speed regulated to some determined bitrate. This bitrate is either determined from the source stream incoming rate, from the <limit-rate> setting or kb value in the name of the file eg /fallback[64k].mp3. If all those are missing then a 404 is returned even if the file is present.



This item and some posts concern me...

I use fallback files to handle the transient nature of my mounts/sources....

I guess I don't understand the "rate-limit" thingy....my understanding is that the mp3 file of the fallback must match the rate of the source, period. full stop. no ifs ors ands or buts.. So I am a little confuzzled...

The posts that concern me are the "crashes" of IC when users disconnect..I need to confirm these bugs are quashed 100% in both KH branch and post main 2.3.2, which doesn't exhibit this issue, as I get one whack to install this for free, otherwise I have to deal with it....which if not then I will just have them install 2.3.2....

I seem to remember that the KH branch offered some setting like "single ip" or something that would limit connections from one IP to one connection per mount.. in other words some IP could not connect up to 2 -3 mounts? ? ? ?
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Tue Sep 03, 2013 2:00 am    Post subject: Reply with quote

Whenever you have a switch from one input to another then you need to make sure the formats are the same. This definitely means codec, and typically means samplerate, channels and bitrate. Codec changes are a big no-no unless you can do that within a container like ogg. samplerate and channels are usually to be the same as players may be limited in changing the sound device settings. Bitrate changes could happen (VBR works on that principle) but again some players seem to have trouble with that.

The above describes the issue with the content you receive, but it says nothing about how much of it you get. With the main release, a fallback file was sent at a high rate, relying on the player to throttle the link, which works to a point. The problem is it balloons the bandwidth (especially if the player does not throttle the receiving rate) and can cause lag in returning back to a normal stream.

The speed regulation I mentioned is done such that a fallback to file (which loops) requires a target bitrate. As this is a general mechanism for any format, the rate gets determined initially from the originating stream (it should be similar). If that is not available then the limit-rate setting is checked for and then the the [] are checked for. If none of those are present, such as when a listener requests a mount that is not present but falls back to a file that does exist then it would still return a 404 unless that speed information is determined (eventually codec parsing could be added in but it is not currently).

I've not had reports of IC crashes with listener disconnects for some time. A possible issue with the lag calculation was the last time that could trigger something like that.

There hasn't been a single IP use filter in KH, you may be better doing that at the firewall level. The feature request has come up before but I haven't got around to it. It could be useful for blocking repeating requests much like the banned ip list does.

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 -> Icecast Server 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