On Thu, 13 Jan 2005 13:19:08 -0500, Joel Ebel <jbebel@ncsu.edu> wrote:> I asked this questions before, but I think it got lost/ignored in all > the traffic. So I'm asking it again. > > Why would my clients number always be 113 larger than my number of > listeners? It was right earlier today, but when I restarted the sources > it increased by 113, and it has stayed that high since then. I find it > especially odd since I have clients set to 100 in icecast.xml, and this > constantly exceeds it. > > Where does this number come from, and what does it mean if it isn't the > sum of the clients for each stream? I know it should include static > content as well, but I don't have 113 clients constantly downloading > static content. And why is it allowed to exceed my max clients anyway? > > I actually asked another question too, but I think I'll ask one at a > time this time so it's more likely to get noticed. > > JoelThat's very strange. I've never seen that behaviour. Perhaps you could give some more detailed explanations of how you've got things set up? At a minimum: - icecast version (and what platform you're running it on) - icecast config file (with passwords blanked out, of course) - description of _precisely_ what figure you're looking at that's 113 off, and where you found that number. - description of what sources you have connected, etc. Mike
Michael Smith wrote:> On Thu, 13 Jan 2005 13:19:08 -0500, Joel Ebel <jbebel@ncsu.edu> wrote: > >>I asked this questions before, but I think it got lost/ignored in all >>the traffic. So I'm asking it again. >> >>Why would my clients number always be 113 larger than my number of >>listeners? It was right earlier today, but when I restarted the sources >>it increased by 113, and it has stayed that high since then. I find it >>especially odd since I have clients set to 100 in icecast.xml, and this >>constantly exceeds it. >> >>Where does this number come from, and what does it mean if it isn't the >>sum of the clients for each stream? I know it should include static >>content as well, but I don't have 113 clients constantly downloading >>static content. And why is it allowed to exceed my max clients anyway? >> >>I actually asked another question too, but I think I'll ask one at a >>time this time so it's more likely to get noticed. >> >>Joel > > > That's very strange. I've never seen that behaviour. Perhaps you could > give some more detailed explanations of how you've got things set up? > > At a minimum: > - icecast version (and what platform you're running it on)Icecast 2.2.0 running on Slackware Linux 10.0> - icecast config file (with passwords blanked out, of course)Config file is attached> - description of _precisely_ what figure you're looking at that's > 113 off, and where you found that number.I've attached a stats.xml which I got from my icecast server as I was typing this email. At the top you see "<clients>131</clients>" Under the sources below there is a <listener> value for each. The non-zero values of these are 3, 4, 1, 2, and 8. The sum of which is 18. 131 - 18 = 113. Every time I look at this, the listeners is different, but their sum is always 113 less than the value of <clients>. When I first started the server, this wasn't true. The sum of the <listeners> was equal to <clients>. At some point it changed. In any case, as you can see in my icecast.xml, <clients> is set to 100, so I feel like the <clents> is stats.xml shouldn't exceed it, but it does.> - description of what sources you have connected, etc.I have 12 sources connected. 6 man streams using darkice, and 6 backup streams using ezstream set up as fallbacks with overrides. half the streams are ogg, half are mp3. For each there is a low, medium, and high quality stream. I have the potential for one more high quality stream set up in the config. That's for a backup studio to transmitter link, but that's not currently in service. If there's any more information I can provide that would be helpful, I'd be more than happy to do so. I can probably restart this server and get it back to normal, but I don't really want to disconnect all my listers, and I would like to track down the source of the inconsistency. Joel -------------- next part -------------- A non-text attachment was scrubbed... Name: icecast.xml Type: text/xml Size: 7617 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast/attachments/20050113/096826d9/icecast.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: stats.xml Type: text/xml Size: 6246 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast/attachments/20050113/096826d9/stats.bin
On Thu, 13 Jan 2005 19:11:08 -0500, Joel Ebel <jbebel@ncsu.edu> wrote:> > - icecast version (and what platform you're running it on) > Icecast 2.2.0 running on Slackware Linux 10.0 > > > - icecast config file (with passwords blanked out, of course) > Config file is attached > > > - description of _precisely_ what figure you're looking at that's > > 113 off, and where you found that number. > I've attached a stats.xml which I got from my icecast server as I was > typing this email. At the top you see "<clients>131</clients>" Under > the sources below there is a <listener> value for each. The non-zero > values of these are 3, 4, 1, 2, and 8. The sum of which is 18. 131 - > 18 = 113. Every time I look at this, the listeners is different, but > their sum is always 113 less than the value of <clients>. When I first > started the server, this wasn't true. The sum of the <listeners> was > equal to <clients>. At some point it changed. In any case, as you can > see in my icecast.xml, <clients> is set to 100, so I feel like the > <clents> is stats.xml shouldn't exceed it, but it does.I suspect this is just a stats bug. The stats are tracked independently from the actual core datastructures that determine how many current listeners there are, how many are allowed, etc. So though this might be a little annoying, it doesn't look critical. There's probably some case somewhere that can cause a connection to counted, but the corresponding disconnection to not be counted. We'll look into it. Mike
Joel Ebel wrote:> <clients>100</clients> > <sources>13</sources>Hey, don't know if it's relevant, but these add up to 113. Geoff. -- Geoff Shang <geoff@hitsandpieces.net> Phone: +61-418-96-5590 MSN: geoff@acbradio.org Make sure your E-mail can be read by everyone! http://www.betips.net/etc/evilmail.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
Apparently Analagous Threads
- client connections seems high
- client connections seems high
- listener authentication for multiple mountpoints; client connections seems high
- client connections seems high
- Icecast locks with WARN connection/_accept_connection accept() failed with error 24: Too many open files