View previous topic :: View next topic |
Author |
Message |
DJ-Zath
Joined: 11 Feb 2009 Posts: 155 Location: Western Illinois - USA
|
Posted: Sun Nov 08, 2009 11:17 pm Post subject: v2.3.2 | mounts not ahearing to assignments |
|
|
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-
|
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Mon Nov 09, 2009 12:15 am Post subject: |
|
|
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 |
|
|
DJ-Zath
Joined: 11 Feb 2009 Posts: 155 Location: Western Illinois - USA
|
Posted: Tue Nov 10, 2009 12:36 am Post subject: |
|
|
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-
|
|
Back to top |
|
|
DJ-Zath
Joined: 11 Feb 2009 Posts: 155 Location: Western Illinois - USA
|
Posted: Tue Nov 10, 2009 12:47 am Post subject: |
|
|
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-
|
|
Back to top |
|
|
DJ-Zath
Joined: 11 Feb 2009 Posts: 155 Location: Western Illinois - USA
|
Posted: Tue Nov 10, 2009 12:56 am Post subject: |
|
|
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-
|
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Nov 10, 2009 1:49 am Post subject: |
|
|
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 |
|
|
DJ-Zath
Joined: 11 Feb 2009 Posts: 155 Location: Western Illinois - USA
|
Posted: Wed Nov 11, 2009 10:49 am Post subject: |
|
|
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-
|
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed Nov 11, 2009 1:08 pm Post subject: |
|
|
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 |
|
|
DJ-Zath
Joined: 11 Feb 2009 Posts: 155 Location: Western Illinois - USA
|
Posted: Mon Nov 16, 2009 11:05 am Post subject: |
|
|
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-
|
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Mon Nov 16, 2009 2:20 pm Post subject: |
|
|
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 |
|
|
DJ-Zath
Joined: 11 Feb 2009 Posts: 155 Location: Western Illinois - USA
|
Posted: Tue Nov 17, 2009 12:33 am Post subject: |
|
|
Hi Karl!
Once again, thank you for the response..
ooHHoo
seems we have both misunderstood each other!
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.
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
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!
-DjZ-
|
|
Back to top |
|
|
|
|
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
|