Jeroen van Oosten
2015-Dec-06 12:13 UTC
[Icecast] Listener statistics on a fallback stream
Hello, I've come across a small problem and I'm not sure it's a bug or a misconfiguration in icecast, so I thought I'd ask here. The situation: we have an automated radio station that is fed from a dedicated virtual machine with SAM broadcaster. I set up a stream with a fallback mount; SAM connects to the fallback. Now, whenever the DJ wants to broadcast live all he has to do is start up his studio and connect to the 'real' stream, thus taking over the stream without having to logon to the server, stop encoders, etc. When he's done he disengages the stream and listeners are automatically back on the automated stream. This setup may be somewhat unusual in that we're running in "fallback" mode most of the time. The problem I have is that the listener statistics are now on the fallback stream, not the 'real' one, so now are listener graphs are flat at zero :( Of course I could pull the statistics from the fallback mount, but then we won't have listener stats for when we're live. To me it sounds like a bug; surely the fallback never needs statistics, only the real steam because this is where listeners connect to. Or maybe I need a different configuration. This the portion of my configuration that deals with the streams: <mount type="normal"> <mount-name>/high.mp3</mount-name> <fallback-mount>/high-server.mp3</fallback-mount> <fallback-override>1</fallback-override> </mount> <mount type="normal"> <mount-name>/high-server.mp3</mount-name> <public>0</public> <hidden>1</hidden> </mount> Listeners are directed to http://radiogfm.dyndns.org:8200/high.mp3, SAM connects to .../high-server.mp3. There are also 2 ACC+ streams with the same structure. So, what I want to know is: how do I get the proper listener statistics from /high.mp3? Is it a bug? Is there a different configuration that will work? The main requirement is that switching over to live streaming is effortless, i.e. just turn on the encoder on the DJ machine and start streaming. Thanks in advance, Jeroen -- Bankai Software Jeroen van Oosten Telefoon: 010-4134567 E-mail: jvoosten at bankai.nl KvK inschrijving: 24455492 "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair
> > >To me it sounds like a bug; surely the fallback never needs statistics, > only the real steam because this is where listeners connect to.Well, the fallback mount is still a mount-point nonetheless. you could still use it as a "regular" mount-point even if its configured as a fallback to another. Now, as for the statistics, should we be able to help without knowing what system you use to gather your statistics and build those charts? or i missed it? anyway, i can think of two options: 1. gather statistics for both mount-points. 2. depend on the software you use, you can write some code to determinate whether a live source is connected and pull the stats from the relevant mount-point accordingly. On Sun, Dec 6, 2015 at 2:13 PM, Jeroen van Oosten <jvoosten at bankai.nl> wrote:> Hello, > > I've come across a small problem and I'm not sure it's a bug or a > misconfiguration in icecast, so I thought I'd ask here. > > The situation: we have an automated radio station that is fed from a > dedicated virtual machine with SAM broadcaster. I set up a stream with a > fallback mount; SAM connects to the fallback. Now, whenever the DJ wants > to broadcast live all he has to do is start up his studio and connect to > the 'real' stream, thus taking over the stream without having to logon > to the server, stop encoders, etc. When he's done he disengages the > stream and listeners are automatically back on the automated stream. > This setup may be somewhat unusual in that we're running in "fallback" > mode most of the time. > > The problem I have is that the listener statistics are now on the > fallback stream, not the 'real' one, so now are listener graphs are flat > at zero :( Of course I could pull the statistics from the fallback > mount, but then we won't have listener stats for when we're live. > > To me it sounds like a bug; surely the fallback never needs statistics, > only the real steam because this is where listeners connect to. Or maybe > I need a different configuration. > > This the portion of my configuration that deals with the streams: > > <mount type="normal"> > <mount-name>/high.mp3</mount-name> > <fallback-mount>/high-server.mp3</fallback-mount> > <fallback-override>1</fallback-override> > </mount> > <mount type="normal"> > <mount-name>/high-server.mp3</mount-name> > <public>0</public> > <hidden>1</hidden> > </mount> > > Listeners are directed to http://radiogfm.dyndns.org:8200/high.mp3, SAM > connects to .../high-server.mp3. There are also 2 ACC+ streams with the > same structure. > > So, what I want to know is: how do I get the proper listener statistics > from /high.mp3? Is it a bug? Is there a different configuration that > will work? The main requirement is that switching over to live streaming > is effortless, i.e. just turn on the encoder on the DJ machine and start > streaming. > > Thanks in advance, > > Jeroen > > -- > Bankai Software > Jeroen van Oosten > Telefoon: 010-4134567 > E-mail: jvoosten at bankai.nl > KvK inschrijving: 24455492 > > "If you think it's expensive to hire a professional to do the job, wait > until you hire an amateur." --Red Adair > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >-- Yahav Shasha, Web Developer +972-(0)549214421 http://www.linkedin.com/in/yahavs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast/attachments/20151206/9117152d/attachment.htm
Jeroen van Oosten
2015-Dec-06 13:41 UTC
[Icecast] Listener statistics on a fallback stream
Hello, On 06-12-15 13:58, Yahav Shasha wrote:> > >To me it sounds like a bug; surely the fallback never needs > statistics, > only the real steam because this is where listeners connect to. > > > Well, the fallback mount is still a mount-point nonetheless. you could > still use it as a "regular" mount-point even if its configured as a > fallback to another.Hmm, you have a point there. But the point is, the *listeners* connect to a certain mount point; I want to count them there. What's happening behind the scenes to get the music to them (be it a fallback stream or even a file played from disk) is irrelevant.> > Now, as for the statistics, should we be able to help without knowing > what system you use to gather your statistics and build those charts? > or i missed it?No you didn't miss it; I'm using a homebrew XSLT to present the information in a simple, parseable format: <xsl:stylesheet xmlns:xsl = "http://www.w3.org/1999/XSL/Transform" version = "1.0" > <xsl:output omit-xml-declaration="no" method="text" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" indent="yes" encoding="UTF-8" /> <xsl:template match = "/icestats" >MountPoint,Connections,Stream Name,Current Listeners,Description,Currently Playing,Stream URL Global,Client:<xsl:value-of select="connections" /> Source: <xsl:value-of select="source_connections" />,,<xsl:value-of select="listeners" />,, <xsl:for-each select="source"> <xsl:value-of select="@mount" />,,<xsl:value-of select="name" />,<xsl:value-of select="listeners" />,<xsl:value-of select="description" />,<xsl:value-of select="artist" /> - <xsl:value-of select="title" />,<xsl:value-of select="url" /> <xsl:text> </xsl:text> </xsl:for-each> </xsl:template> </xsl:stylesheet> The output is a text file that I can easily parse from a script; the output is fed into MRTG. At this moment, the 'real' mount points are missing from this output, even though clients are connected.> anyway, i can think of two options: > 1. gather statistics for both mount-points.I thought of that, but the fallback mounts are hidden so I don't get the info at all. They are hidden simply because I don't want to show them up to the users on the statistics page.> 2. depend on the software you use, you can write some code to > determinate whether a live source is connected and pull the stats from > the relevant mount-point accordingly.Way too complicated. Why should I bother "switching" between mount points when my listeners connect to a single mount point? I'm beginning to think this is a 'feature' of IceCast with unintended consequences... Thanks, Jeroen -- Bankai Software Jeroen van Oosten Telefoon: 010-4134567 E-mail: jvoosten at bankai.nl KvK inschrijving: 24455492 "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast/attachments/20151206/fd1f23d0/attachment.htm
Goedemorgen. On Sun, 2015-12-06 at 13:13 +0100, Jeroen van Oosten wrote:> Hello, > > I've come across a small problem and I'm not sure it's a bug or a > misconfiguration in icecast, so I thought I'd ask here. > > The situation: we have an automated radio station that is fed from a > dedicated virtual machine with SAM broadcaster. I set up a stream with a > fallback mount; SAM connects to the fallback. Now, whenever the DJ wants > to broadcast live all he has to do is start up his studio and connect to > the 'real' stream, thus taking over the stream without having to logon > to the server, stop encoders, etc. When he's done he disengages the > stream and listeners are automatically back on the automated stream. > This setup may be somewhat unusual in that we're running in "fallback" > mode most of the time.Ok, That is fine so far. Even a quite common setup.> The problem I have is that the listener statistics are now on the > fallback stream, not the 'real' one, so now are listener graphs are flat > at zero :( Of course I could pull the statistics from the fallback > mount, but then we won't have listener stats for when we're live. > > To me it sounds like a bug; surely the fallback never needs statistics, > only the real steam because this is where listeners connect to. Or maybe > I need a different configuration.Ok, I think there is some confusion here: There is *no* difference between a mount used as fallback and one that isn't. The only difference is in the configuration of the mount falling to a specific other mount. That is also why the config looks like it does. When a stream falls back to another one the listeners are *moved* from one to the other mount. So they are no longer on the mount they entered. Therefore they're not on it's statistics.> This the portion of my configuration that deals with the streams: > > <mount type="normal"> > <mount-name>/high.mp3</mount-name> > <fallback-mount>/high-server.mp3</fallback-mount> > <fallback-override>1</fallback-override> > </mount> > <mount type="normal"> > <mount-name>/high-server.mp3</mount-name> > <public>0</public> > <hidden>1</hidden> > </mount> > > Listeners are directed to http://radiogfm.dyndns.org:8200/high.mp3, SAM > connects to .../high-server.mp3. There are also 2 ACC+ streams with the > same structure.Beside that you use non-free codecs this looks fine to me. (And it seems to work fine for you beside the statistics problem).> So, what I want to know is: how do I get the proper listener statistics > from /high.mp3? Is it a bug?They are proper and there is no bug here.> Is there a different configuration that will work? > The main requirement is that switching over to live streaming > is effortless, i.e. just turn on the encoder on the DJ machine and start > streaming.Ok, I after clarifying (at least I hope so) above here is what I would suggest: If you only have a 1:1 mapping between entry and fallback mounts I would just sum up the numbers. If there is a more complicated mapping you can used more advanced options to track how listeners move between mounts. E.g. based on the event of entry update your statistical data. What the best option is depends a bit on what you're using and how. On the other mail you mentioned MRTG. I think it supports both a broad way of adding data. Both poll and trigger based. If you like I can asks our in-house MRTG staff for his opinion. Have a good Sunday! -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part Url : http://lists.xiph.org/pipermail/icecast/attachments/20151206/627fa934/attachment.pgp
Jeroen van Oosten
2015-Dec-07 18:41 UTC
[Icecast] Listener statistics on a fallback stream
Hello, On 06-12-15 15:41, Philipp Schafft wrote:>> The problem I have is that the listener statistics are now on the >> fallback stream, not the 'real' one, so now are listener graphs are flat >> at zero :( Of course I could pull the statistics from the fallback >> mount, but then we won't have listener stats for when we're live. >> >> To me it sounds like a bug; surely the fallback never needs statistics, >> only the real steam because this is where listeners connect to. Or maybe >> I need a different configuration. > > Ok, I think there is some confusion here: > There is *no* difference between a mount used as fallback and one that > isn't. The only difference is in the configuration of the mount falling > to a specific other mount. That is also why the config looks like it > does. > > When a stream falls back to another one the listeners are *moved* from > one to the other mount. So they are no longer on the mount they entered. > Therefore they're not on it's statistics.You know, I have a problem with the term 'moved'. The way it is worded it seems to indicate that the clients are actively moved to a different URL (by some special codes in the stream, like a HTTP redirect or something), which is not the case. It is only an internal 'move' between mount points. At least that much is clear now.> Beside that you use non-free codecs this looks fine to me. (And it seems to work fine for you besidethe statistics problem). This is a bit beside the point, but give a me a free (open source) codec that works reasonably for music at 28/56 kbit and works on all platforms, and I'll switch tomorrow :P We had an Ogg stream for years, nobody used it. Sorry, but that's the way it is.>> Is there a different configuration that will work? >> The main requirement is that switching over to live streaming >> is effortless, i.e. just turn on the encoder on the DJ machine and start >> streaming. > > Ok, I after clarifying (at least I hope so) above here is what I would > suggest: > If you only have a 1:1 mapping between entry and fallback mounts I would > just sum up the numbers.That seems to be the most logical solution for now, though from my point of view it looks silly. I can have 10 different 'input' streams, there is only one stream/mount point our listeners connect to and that's the one I'm interested in; the rest are technical details. I'm sure there's a technical / architectural reason for this but clearly designed for a different use case.> What the best option is depends a bit on what you're using and how. > On the other mail you mentioned MRTG. I think it supports both a broad > way of adding data. Both poll and trigger based. If you like I can asks > our in-house MRTG staff for his opinion.Thanks, but getting the statistics into MRTG isn't a problem. I'll just need to extend the script(s) a bit. Regards, Jeroen van Oosten -- Bankai Software Jeroen van Oosten Telefoon: 010-4134567 E-mail: jvoosten at bankai.nl KvK inschrijving: 24455492 "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast/attachments/20151207/787de017/attachment.htm