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 

Interesting snags!

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



Joined: 11 Feb 2009
Posts: 155
Location: Western Illinois - USA

PostPosted: Wed Aug 27, 2014 1:54 pm    Post subject: Interesting snags! Reply with quote

first off, Hey Karl and gang!

I hope everyone's in good health and spirits!

now.. I need some HELP and advice!

I have used Icecast for my streaming service for many years and consider it one of the best streaming servers out there..

however, I've ran into a couple caveats with using it for my particular function...

let me see if I can explain.

1.. NO means to assign multiple passwords to casters for a single global mount.. sure, one can create mounts- BUT.. mounts have to be daisy-chained and/or separated to each its own.. get a few mounts chained and you run into "priority" issues.. what would really be nice, in this case, is a "or switch" or means to switch mounts to a master mount with EQUAL priority..

BUT.., I use a "time share" system and, therefore, need a way to implement a means to assign passwords to casters for use on a single mount.. especially, recently, where I now have a disgruntled caster.. since I curently only have ONE password shared by all the broadcasters.. well, you can see the drama that's going to ensue!

SO.. I have come up with a neat little idea.. I have taken another streaming server software (NOT DNAS!) and paired it with Icecast by having Icecast relay the other server's output via a local port; this software DOES support a password checklist that can be set on-the-fly.. however, I ran into a SNAG.. I can't get icecast to change its "relay retry timeout" and when an incoming feed is taking 2 MINUTES or MORE to be "detected" and forwarded by icecast, thats a real bummer! Sad I scoured the docs and found NOTHING that works.. yes, even the <retry-delay>10</retry-delay> does NOT appear to work.. (this setting doesn't appear to work at all even for ANY relay mount or input stream; I think its broken!) Icecast just "defaults" to a timeout and wait of 2 to 5 minutes PER DJ login.. this is NO GOOD Sad any help/ideas would be greatly-appreciated! Smile

and 2...

another odd "bug" I have come across (I've known about this one for years)... let's see if I can explain this one.. you have one "main" mount that the public tunes into... then you have another mount behind it.. that "forwards" to the main mount that's in front of it. .. this second mount has a receiver tuned into it- but its only meant for a private listener... now, lets say the first mount has a caster on its input.. this mount has a listener and also the mount after it if forwarding to the public... all is good... now, the MAIN mount now gets a source logged in.. the first mount's listener will SWITCH to the MAIN mount!

why is this bad? you may be thinking... well I have a system where I have a "master studio" that listens to the "input" mount while casting to the "main" mount.. there's a AUDIO CONSOLE AND PROCESSING RACKS inline to this path.. when this "bug" occurs, the output of said equipment all-of-a-sudden becomes connected back to its own INPUT! OOPS! VERY VERY BAD!

luckily I found a FIX for this.. sorta.. (and what a clusterf**k is is to correct!) and, for years I have found the solution, however, since this new issue with having to use a "relay" mount instead of an input mount.. well, the bug is BACK!

UGHH!!

anyhow, I was hoping someone out there has a solution for the "super-long-detect-and-connect" issue... (I kinda have the other bug under control, at least for now while I'm writing this post..)

-DjZ-
_________________
-DjZ-
Smile Smile
Back to top
View user's profile Send private message Visit poster's website
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Thu Aug 28, 2014 1:34 pm    Post subject: Reply with quote

1 you can use a stream_auth authentication option to allow for an external url (eg php) to do the verification on source connect using whatever criteria you wish. With the KH build you can even return back the icecast-auth-user: hijack header to get it to kick off any existing source client. If you use that then be wary that the previous source will try to reconnect, so you will want to either reject or not use hijack in such cases.

you can of course us the move clients admin request to move listeners from one mount to another which may be useful if you have a relay mount (for listeners) jumping between internal mountpoints used by different streamers.

as for the retry-delay query, I would need to look into specifics of what you have configured to see what the issue actually is. I may be just too sleepy to grasp it yet.

2. not sure I'm following you on this, you seem to refer to a second and first as well as a main mountpoint, I'm not sure on the associations on those. If you want you can expand on the specifics in an email. sounds like a fallback path is being used by a feed that you don't want used. sometimes that can be isolated by a separate mountpoint.

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



Joined: 11 Feb 2009
Posts: 155
Location: Western Illinois - USA

PostPosted: Thu Aug 28, 2014 2:42 pm    Post subject: Reply with quote

hi Karl!

and thanks for the reply!

I think I have confused you a tad.. I shall try to explain thigs a little more deeply..

first off, I have discovered a nasty bug in Icaecast from years ago.. AND this bug STILL exists in the current/latest build

the bug consists of a specific situation where if 2 mounts are linked by a fallback AND if/while the previous mount has a feed on it and then the second mount's source comes online, the output from the first mount switches to the second mount..

example:

when working properly...

audio ONE -> /mount 1 -> fallback -> /mount 2 -> output =

out from mount one-> audio ONE, out from mount 2 -> audio ONE

BUT.. if..

audio ONE -> /mount 1 |(and then mount 2 logs in)| audio TWO -> /mount 2 -> output =

audio TWO on BOTH mount outputs

and... that is the bug!


Now, I have a setup where:

audio ONE -> /mount 1 -> STUDIO EQUIPMENT -> audio TWO -> /mount 2 -> output

the studio equipment's output ends up BACK on mount 1's output and into the equipment's input and causes a GIANT FEEDBACK LOOP...

VERY VERY BAD!!!

this is a NASTY bug that's never been corrected

HOWEVER..

I found that if I use the following configuration, it prevents the issue..

/mount one -> /relay to LOCALHOST -> mount 2

this served me for years...

but the caveat is that I have to use icecast's input in "shoutcast" mode for /mount 1

with a mount block and a single password.. (the web interface is NOT used in ANY way)

the idea is that in case the studio is absent, that /mount 2 will "fall back" to /mount 1

now... the dilemma

the idea is for a completely AUTOMATIC system where DJs do NOT have access to the admin panel and theres no kick scripts or otherwise management available to signing DJs on and off.. there's is no access to icecast itself as its fully-proxied from the internet..

but, now due to a recent development where a DJ was fired.. this DJ still has the "cast password".. and in the past, I ended up having to CHANGE said password and this becomes messy.. I'm doing this TOO much as of lately..

SO, I came up with a solution... I can load another streaming software that I had written for my system before I started using Icecast that allows passwords to be accessed from a list internally and apply on-the-fly without resetting the Cast software... we will refer to this as {SR}, I have Icecast relay the software's output into a /relay mount..

here's the basic map.. simple enough...

DJ -> {SR} -> /relay -> /mount 2 -> output

but, lone behold- the BUG is BACK!

so I did it this way...

DJ -> {SR} -> /relay 1 -> /mount 1 -> /relay 2 -> /mount 2 -> output

and the same route with the studio inline:

DJ -> {SR} -> /relay 1 -> /mount 1 -> /relay 2 -> STUDIO EQUIPMENT -> /mount 2 -> output

this, again, eliminates the bug.. but what a clusterf**k it is!

note that mount 1 doesn't handle ANY logins its just "there" (its password is nulled/randomized..)

the bug is dealt with.. but theres another issue I can't seem to correct

the first /relay mount won't "stay connected" to the {SR} output if there's no-one there.. that makes sense, of course, however, then icecast takes 2 to 5 MINUTES to attempt a connection again.. I can't seem to shorten this "delay" even with the <retry-delay> flag.. (in fact, <retry-delay> doesn't seem to be settable at all to ANY relay mount and I think this is broken/another bug). so, the end result is even if the studio is online, a DJ logging in doesn't "go to air" for 2 to 5 minutes.. and this is a unacceptable condition..

so, that's where I am stuck!

if you would like a demo of this, come and visit http://www.warp-radio.com and look for me in the chat room and I can alos further explain how all of this works (or, not works)
_________________
-DjZ-
Smile Smile
Back to top
View user's profile Send private message Visit poster's website
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sat Aug 30, 2014 11:08 pm    Post subject: Reply with quote

wrt the retry-delay, I'd have to see what you have actually configured with the <relay> block and source-timeout. The retry-delay just overrides the master-update-interval value (120 seconds default) for that particular relay.

The core issue sounds like you are falling back the wrong thing and need the studio to read from a non-fallback mount eg

source feeds /mount1
source feeds /mount2
studio equipment reads from /mount1
relay /internal takes from /mount1
/mount2 fallback to /internal

the /internal mountpoint then isolates external listeners from the studio equipment, and only those listeners get dragged back up to /mount2. icecast does not know that you don't want the studio connection to be moved.

Regarding auth for sources, you can use the url auth on mount 1

<option name="stream_auth" value="http:..." />

to allow for multiple access by different users/password/IPs. Even works with shoutcast sources (obviously the username is of little use in such cases). Then you can use whatever the script uses to change the acceptable parameters.

If you really don't like the idea of a /internal mount then you could have them connect as if it's a slave relay eg /admin/streams?mount=/mount1 as these slave relay connections don't follow fallback links and skip over certain limits like max-listeners.


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