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 

v2.3.2 | mounts not ahearing to assignments

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



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

PostPosted: Sun Nov 08, 2009 11:17 pm    Post subject: v2.3.2 | mounts not ahearing to assignments Reply with quote

this isn't a serious bug, however, I should report it just the same...

Bug description:

When using multiple mounts which are assigned. the last mount will output on all previous mounts- globally. Seems to occur at startup especially.

This ones hard to explain, but given a specific situation, this nasty little bugger causes a "feedback loop" condition where the output mount appears at the input mount's output!

Condition:

I have set up a series of mounts, in "pairs" of input and output, and the output mount is set to "fallback" to the input mount.

Heres what supposed to happen and what actually happens:

"remote" cast comes in on /input, is then retrieved on /input, and then sent to the studio console where its then sent back to /output.

remote -> /input -> studio -> /output = OK

what happens instead, is /output will appear at /input's receiver..

/input (with /output's output) -> studio ->/output = VERY BAD!

I have come up with a way to "get around" this bug.. but at a cost of passing streams from one mount to another to another locally (on 127.0.0.1)... Although this prevents the "feedback bug", I think this is costly on resources, however, and I have to set an alias for the /relay mount to prevent listeners from tuning into it.

remote -> /input -> /relay (local) -> studio -> /output = OK

heres a "condensed" version of my config file:

Code:


<icecast>

<hostname>warp-radio.com</hostname>

<listen-socket>
        <port>8000</port>
        <bind-address>64.6.9.129</bind-address>
        <shoutcast-mount>/input</shoutcast-mount>
</listen-socket>

<listen-socket>
        <port>8000</port>
        <bind-address>127.0.0.1</bind-address>
</listen-socket>

<limits>
        <sources>5</sources>
        <threadpool>8</threadpool>
        <queue-size>256000</queue-size>
        <client-timeout>2</client-timeout>
        <header-timeout>3</header-timeout>
        <source-timeout>5</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>128000</burst-size>
</limits>

<authentication>
        <admin-user>admin-user</admin-user>
        <admin-password>admin-password</admin-password>
</authentication>

<mount>
        <mount-name>/input</mount-name>
        <password>remote-password</password>
        <genre>Mixed Techno Rock Comedy</genre>
        <no-yp>1</no-yp>
        <public>0</public>
        <hidden>1</hidden>
</mount>

<mount>
        <mount-name>/warp-128.mp3</mount-name>
        <password>studio-password</password>
        <burst-size>136000</burst-size>
        <fallback-mount>/relay</fallback-mount>
        <fallback-override>1</fallback-override>
        <fallback-when-full>0</fallback-when-full>
        <public>1</public>
        <stream-name>WARP Radio Network - 128k MP3 Broadband Feed</stream-name>
        <stream-description>"Where The Masses Get WARP'ed!"</stream-description>
        <stream-url>http://www.warp-radio.com</stream-url>
        <genre>Mixed Techno Rock Comedy</genre>
        <intro>/icecast-128.mp3</intro>
        <bitrate>128</bitrate>
        <type>audio/mpeg</type>
        <subtype>mp3</subtype>
        <mp3-metadata-interval>32768</mp3-metadata-interval>
        <hidden>0</hidden>
</mount>

<relay>
        <server>127.0.0.1</server>
        <port>8000</port>
        <mount>/input</mount>
        <local-mount>/relay</local-mount>
        <on-demand>1</on-demand>
        <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
        <no-yp>1</no-yp>
        <hidden>1</hidden>
        <public>0</public>
</relay>

<paths>
        <basedir>icecast</basedir>
        <logdir>icecast</logdir>
        <webroot>icecast</webroot>
        <adminroot>icecast</adminroot>
        <pidfile>icecast/iceast.pid</pidfile>
        <alias source="/relay" dest="/warp-128.mp3"/>
        <alias source="/" dest="/warp-128.mp3"/>
        <alias source="" dest="/warp-128.mp3"/>
</paths>

<logging>
        <accesslog>icecast.tmp</accesslog>
        <errorlog>icecast.tmp</errorlog>
        <playlistlog>icecast.tmp</playlistlog>
        <loglevel>0</loglevel>
        <logarchive>0</logarchive>
</logging>

<fileserve>0</fileserve>

</icecast>


now, this is a working config that includes the workaround to the "feedback loop" bug...

heres the same code, but without the workaround:
Code:

<icecast>

<hostname>warp-radio.com</hostname>

<listen-socket>
        <port>8000</port>
        <bind-address>64.6.9.129</bind-address>
        <shoutcast-mount>/input</shoutcast-mount>
</listen-socket>

<listen-socket>
        <port>8000</port>
        <bind-address>127.0.0.1</bind-address>
</listen-socket>

<limits>
        <sources>5</sources>
        <threadpool>8</threadpool>
        <queue-size>256000</queue-size>
        <client-timeout>2</client-timeout>
        <header-timeout>3</header-timeout>
        <source-timeout>5</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>128000</burst-size>
</limits>

<authentication>
        <admin-user>admin-user</admin-user>
        <admin-password>admin-password</admin-password>
</authentication>

<mount>
        <mount-name>/input</mount-name>
        <password>remote-password</password>
        <genre>Mixed Techno Rock Comedy</genre>
        <no-yp>1</no-yp>
        <public>0</public>
        <hidden>1</hidden>
</mount>

<mount>
        <mount-name>/warp-128.mp3</mount-name>
        <password>studio-password</password>
        <burst-size>136000</burst-size>
        <fallback-mount>/input</fallback-mount>
        <fallback-override>1</fallback-override>
        <fallback-when-full>0</fallback-when-full>
        <public>1</public>
        <stream-name>WARP Radio Network - 128k MP3 Broadband Feed</stream-name>
        <stream-description>"Where The Masses Get WARP'ed!"</stream-description>
        <stream-url>http://www.warp-radio.com</stream-url>
        <genre>Mixed Techno Rock Comedy</genre>
        <intro>/icecast-128.mp3</intro>
        <bitrate>128</bitrate>
        <type>audio/mpeg</type>
        <subtype>mp3</subtype>
        <mp3-metadata-interval>32768</mp3-metadata-interval>
        <hidden>0</hidden>
</mount>

<paths>
        <basedir>icecast</basedir>
        <logdir>icecast</logdir>
        <webroot>icecast</webroot>
        <adminroot>icecast</adminroot>
        <pidfile>icecast.pid</pidfile>
        <alias source="/relay" dest="/warp-128.mp3"/>
        <alias source="/" dest="/warp-128.mp3"/>
        <alias source="" dest="/warp-128.mp3"/>
</paths>

<logging>
        <accesslog>icecast.tmp</accesslog>
        <errorlog>icecast.tmp</errorlog>
        <playlistlog>icecast.tmp</playlistlog>
        <loglevel>0</loglevel>
        <logarchive>0</logarchive>
</logging>

<fileserve>0</fileserve>

</icecast>



This example will exhibit the "feedback loop" bug.

the bug occurs if the server is started, then the "studio" mount is initialized (the studio encoder logging into it) a receiver at the /input mount will receive the studio's output.. in my case, thats fed directly back into the output mount!

if the /input mount is fed with audio BEFORE the /output mount is initialized. the /input mount seems to work properly-SOME OF THE TIME.. however, this is not consistant nor can I rely on that condition to be met EVERY time the server is rebooted.. this is a case that WILL cause severe damage to the studio equipment if this were to occur when the studio is not being monitored...

My question is:

will the workaround be too resourse-intensive to be considered?

-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: Mon Nov 09, 2009 12:15 am    Post subject: Reply with quote

a single relay won't be intensive but I would suggest a small re-arrangement

remote -> /input
/input (relay on-demand) -> /passthru
/input -> studio
/output fallback/override /passthru

This way, /input will have at most 2 listeners (relay and studio), the /passthru relay is only active if /output is not and /passthru separates normal listeners from the studio. You can use alias or auth to prevent external listeners getting /input.

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: Tue Nov 10, 2009 12:36 am    Post subject: Reply with quote

thanks Karl for your reply!

However, I'm not quite following...

I'm not following what /passthru means.. but if its what I'm thinking, thats what I mean by /relay. I'm using the "/relay" as a passthru to "secure" the /input to a global mountpoint.. otherwise, the output mount's audio will end up on it...

Setting "on demand" on causes another strange problem... with that turned on, the relay takes (up to ) 2 minutes to come to life... this results in missing the first few listeners.. expecially during a fallback state where the studio lose the net.. again once this happens, neither the /relay or /warp-128 mounts can reastablish connection for at least 2 minutes...

setting "on demand" off seems to allow a much quicker (re)connection.

-DjZ-
Smile Smile
Back to top
View user's profile Send private message Visit poster's website
DJ-Zath



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

PostPosted: Tue Nov 10, 2009 12:47 am    Post subject: Reply with quote

another strange problem happens with "auth" as well... okay theres two reasons I can't use auth here...

1.. using auth means that listeners need to auth to receive the "emergency fall back" which defeats the purpose of having it in the first place...

2.. the hardware receiver in the racks doesn't support auth (unless perhaps I could use "login:user@ip:port" which I haven't yet tried would that work for auth?)

what Icecast needs is a "VIP" thingy like Steamcast has.. VIP worked very nicely.. but Icecast is far better than Steamcast.. when I did it in Steamcast, I simply set VIP to 127.0.0.1 and the studio's IP and then set auth active.. this allowed only the studio to tune into the input feed but also allowed rerouting the feed tothe main mount without allowing the /input mount access by the outside world.. Icecast still cannot do this.

-DjZ-
Smile Smile
Back to top
View user's profile Send private message Visit poster's website
DJ-Zath



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

PostPosted: Tue Nov 10, 2009 12:56 am    Post subject: Reply with quote

In looking at my code, I realize that "on demand" is allready on!

hmmmm I do recall the "2 minute wait" issue and it having to do with "on demand".. but now I'm not so sure what causes it.. once I find out, I'll post my findings... (currently, the 2 minute wait issue isn't being experienced and I have on-demand set to on)

-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: Tue Nov 10, 2009 1:49 am    Post subject: Reply with quote

my usage of /passthru is defined in the same way as your /relay but you do not separate the studio feed from normal listeners. This is leading yours to have the problems of the mount feeding itself. I'm suggesting that your listeners bounce between the output mountpoint and /passthru, the studio feed stays put on /input. The passthru mount is just a copy of input.

Your description of auth seems to assume the need for a user and password, using URL auth you can auth based on IP or a query arg (eg http://host:8000/input?letmein=now), there is an argument for having a per-mount allow/deny ip file for listener and/or source clients.

If a relay is on-demand that the stream is only tried when the first listener is put on, but if not on-demand then the relay is retried every <master-update-interval> seconds (default 2 mins).

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: Wed Nov 11, 2009 10:49 am    Post subject: Reply with quote

Hi karl!

hmmm..

I'm still not quite following.. but I'll try to explain my setup a little more in detail..

/input is the remote DJ input.. they send a feed to mount /input

from here /input is either pulled back down to a receiver in the racks at the studio OR, if the studio loses the net, then /input is "fall-back"ed to /warp-128.mp3 which IS the studio mount. When the studio is present, then the encoder in the racks feeds /warp-128.mp3. The "snarfu" here is that /input is an ICY (shoutcast) mount, whereas /warp-128.mp3 is an Icecast2 mount.

I had to write some perl script to turn the UDP (multicast) from the studio encoders to icecast/TCP for the /warp-128.mp3 mount (I have a simular issue for video.. more on that later) I could *NOT* switch or "fall back" 2 ICY mounts or one ICY mount into another ICY mount unless I loaded three seperate server sessions/processes (on seperate ports, of course) and bounced the streams across localhost between the sessions... (now THAT was messy!).

Now where /relay comes in, is that it takes the "floating" /input mount and "secures" it to the chain.. (global assignment?) so that it doesn't "bounce" from any other mount- especially the main /warp-128.mp3 mount!

as for /passthru itself, I donno if that is a built-in designation like /relay? or /mount? or if its an arbitrary name like /warp-128.mp3...

perhaps a simple config layout might help me understand?

the thing is /input has to sit independantly as a stand-alone so the receiver can log into it at any time.. receiver doesn't log into the relay- only the main mount uses the relay as a means to fallback into it.. why this is? I don't know! what I DO know is that without /relay the /input mount will "float" or, as you called it, bounce to the main output mount and start feeding its audio back onto itself!

oh, and I had fun writing code that keeps the "listener numbers" proper during a switchover as well (I call it a "hop detector").

I hope this helps explain what I'm trying to convey.. sometimes I have trouble explaining things to others.

-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: Wed Nov 11, 2009 1:08 pm    Post subject: Reply with quote

The impression I have from your description is that you do not want /relay to be relaying from the output mountpoint. You may of created a fixed point for the studio to read from but that relay itself is reading from a location that is being moved around which is leading to that problem, remember fallback override is enabled and reading end of a relay will be moved. The relay will be treated like a listener by the server providing the content.

What I suggested is to invert that relay aspect, keep the studio feed fixed on /input and have the listeners fallback onto the relay, not the other way around.

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: Mon Nov 16, 2009 11:05 am    Post subject: Reply with quote

hi again karl!

I hope you are in good health and spirits..

Actually, /relay feeds the studio's mount input in-case studio is lost- (net dropout) and /input feeds the /relay.

putting the relay in between /input and /warp-128.mp3 is what solved the problem!

orginally, having /input feeding /warp-128.mp3 was where the "feedback loop" problem was being experienced.

I read that you recommend that I have listeners listen to /relay and to have /relay fed BY /warp-128.mp3.. then that would mean /input would have to feed /warp-128.mp3 and the feedback loop issue happens again. no?

unless you mean /input -> /relay -> /warp-128.mp3 ->/relay#2 ?

I think I see where the misunderstanding is coming from where you are thinking I don't want the listeners on /warp-128.mp3...

the problem I have mostly, is that /input is a shoutcast mount.. so it doesn't exactly "fit" connecting to icecast mounts.. sending it into a /relay seems to "adheare" it to the global mount buss.. and thus, it "stands still" once on the relay's output...
but I think the REAL culprit is on /warp-128.mp3's input! being that this is a icecast2 mount.. since I can't fall back between 2 shoutcast mounts in ANY way...

how can I explain this?? hmmm

/input (ICY)/\/\/\/varying assignment\/\/\/ /relay -----fixed (mountpoint)----- /warp-128.mp3

theres also an encoder and a receiver connected together (through a mixing console) that sits in-between the three..

/input --> receiver --> console --> /warp-128.mp3

in the event that that studio loses the net (which it does quite often!) then the "fallback" kicks in from relay... and from that part, on you understand..

what I can't figure out, however, is why; when /warp-128..mp3 is set to "fall back" to /input.. the receiver listening to /input will pick up /warp-128.mp3 instead!

now we have this: (en-route-speaking)

/warp-128.mp3 -> console ->/warp-128.mp3

since the console is a series of amplifiers.. well, you can guess what happens next...

SMOKE!

like turning on a mic and tossing it in front of the speakers!

well, its more that you hear the "intro" then hear it again, and again and again and so on and so on and so on.... each time degenerating more and more untill it turns into a smouldering heap of white noise!

but, it doesn't do it all the time.. it happens if /warp-128.mp3 is started first. if an remote encoder (DJ) logs into the /input, then it corrects itself .. untill the server is restarted again...

its either a bug.. or I'm not understanding exactly how Icecast works...

or both heheh

hey karl!
I hope you're having a good day out there.

-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: Mon Nov 16, 2009 2:20 pm    Post subject: Reply with quote

a couple of small points to clear up. the difference between shoutcast and icecast source client connections is purely the incoming protocol, when the stream is active then they are treated the same.

You seem to of misunderstood my suggestion on the layout. My suggestion based on my understanding of your setup.

source client feeds /input
studio reads from /input to feed /warp-128.mp3
listeners request /warp-128.mp3 but may fallback to the relay

currently you have

source client feeds /input
studio reads from the relay to feed /warp-128.mp3
listeners request /warp-128.mp3 but may fallback to /input

at the moment your relay which initially reads /input can be altered to read from /warp-128.mp3 because of the fallback override, correct.

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: Tue Nov 17, 2009 12:33 am    Post subject: Reply with quote

Hi Karl!
Once again, thank you for the response..

ooHHoo

seems we have both misunderstood each other! Smile

Quote:

You seem to of misunderstood my suggestion on the layout. My suggestion based on my understanding of your setup.

source client feeds /input
studio reads from /input to feed /warp-128.mp3
listeners request /warp-128.mp3 but may fallback to the relay


This is how I have it now.. (I mean your suggestion) I think the part you misunderstood is that theres a "bypass" when the studio is online that goes over/around /relay and routes /input directly to /warp-128.mp3 This is achieved through another encoder, outside of Icecast completely. You do seem to understand that /relay is in play when /warp-128.mp3's stream is missing/offline, then the "fallback" routes /relay into play. that part you have right. Smile

Quote:

currently you have

Quote:

source client feeds /input

correct - source client being the remote DJ.

Quote:

studio reads from the relay to feed /warp-128.mp3

incorrect - studio reads from /input - /relay is just a passthrough to secure /input to a mountpoint, /relay only relays localhost /input to /warp-128.mp3.

Quote:

listeners request /warp-128.mp3 but may fallback to /input

correct - they get /input (via /relay) if source for /warp-128.mp3 is not present or lost.

Quote:

at the moment your relay which initially reads /input can be altered to read from /warp-128.mp3 because of the fallback override, correct.

incorrect - the /relay only reads /input.. and /warp-128.mp3 only reads /relay when needed.


One could say that /relay isn't even needed, and technically, it isn't
however, if /input were to feed /warp-128.mp3 directly, /input's output can have /warp-128.mp3 on it.. and this causes a feedback loop in the studio console. This exact sanario is the bug I mentioned eariler; this seems to happen when using shoutcast mounts as fallbacks. The "workaround" was to insert a /relay which is a "icecast mount" by trade, that "relays" the shoutcast mount but NOT as a fallback! In essence, its treated as 2 completely isolated streams/servers that happen to share the same instance. This configuration does process the stream twice however, and consumes port traffic on localhost which is why I asked if this could become a potential problem down the line. Being the way I understand how the fallback works, if a large number of listeners were listening, then /relay has to supply a fallback stream to each and every one of them! this CAN and does add up quickly; say there 25 listeners, now icecast and the server has to contend with 50 streams!

and thats why I popped in here initially Smile

The bug doesn't occur when falling-back to another icecast mount, therefore, I had to come up with a way to "convert" the shoutcast mount into an icecast mount.. and thats where /relay comes in. Now, on a slightly different note, but still related to this thread, I have to do the same EXACT thing for the video side of the system as well; but the problem here is I don't have a way to send NSV using true icecast2 protocol (read: logging into the "studio video in mount" -> /warp-cam.nsv) using a shoutcast protocol. (the remote VDJ input allready has the shoutcast mount /relay assignments). Unless I make another "master" mount with a dead input and have a double-fallback.. but that won't work either- why? the BUG! Imagine that; 3 relays all relaying localhost mounts on the same instance.. and nothing has even gone to the listeners/viewers yet!

see what I'm saying? its becoming quite MESSY! Smile

-DjZ-
Smile Smile
Back to top
View user's profile Send private message 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