Fwd: Re: Can't support more than one listener

[Eric Kolotyluk-2]

On 11/8/2009 7:37 AM, Karl Heyes wrote:

>  On 08/11/09 01:24, Eric Kolotyluk wrote:
>
>>  I'm running Icecast 3.2.1 on Windows 7 on my new computer and I've tried
>>  streaming with oddcast as well as shoutcast, but for some reason only
>>  one listener at a time can hear the stream.
>>
>>  I'm running Icecast 2.3.1 on Windows XP on my old computer streaming
>>  with oddcast, and it supports multiple listeners just fine.
>>
>>  Can anyone think of what is wrong with Icecast on my new computer?
>>
>  What makes you think icecast is at fault in this case? are listeners
>  being rejected. Maybe you should look at both log files to see if
>  listeners are trying to connect, and if so why the second connection is
>  being dropped.
>
>  karl.
>
>
>
>  _______________________________________________
>  Icecast mailing list
>  Icecast@...
>  http://lists.xiph.org/mailman/listinfo/icecast
>

I don't know that Icecast is at fault, but I thought I would start with

this maillist to see if anyone here can help. I've attached my Icecast
files to this e-mail.

As far as I can tell, the access.log file shows no indication of
listener activity, at least I can see no correspondence of log lines
that match when the listeners appear in the error.log file. Is there a
way to increase the logging level in this file? Should I be able to see
listeners attaching in this file?

In the error.log file I can see no indication of a two listeners
attempting to connect. I can see where listener-a connects, but there is
no indication of the listener-b attempting to connect. I can see
listener-a disconnect, and then I can see listener-b connect, but there
is no indication of listener-a trying to reconnect. It is possible that
after listener-a connects, Icecast is not event getting a connect
message from listener-b because something else is blocking it out
(Windows or the router)? Maybe I need to install a packet listener on my
system an watch the ethernet traffic?

Possible problems are

1. My router. But I think not because the same router supports multiple
listeners with my old computer, and both computers are connected to the
same router.

2. My new computer is Windows 7 64-bit Ultimate RTM (with two ethernet
connections). My old computer is Windows XP (with one ethernet
connection). It would help if someone else could tell me if they have
Icecast working correctly (or not) on Windows 7.

3. Icecast. I am running Icecast 2.3.1 on both computers (ignore what
I said earlier about 3.2.1), and using the same icecast.xml file
(except the ports are different). This is likely not the problem.

Any more advice would be greatly appreciated.

Cheers, Eric



<icecast>
    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <threadpool>5</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <!-- If enabled, this will provide a burst of data when a client
             first connects, thereby significantly reducing the startup
             time for listeners that do substantial buffering. However,
             it also significantly increases latency between the source
             client and listening client.  For low-latency setups, you
             might want to disable this. -->
        <burst-on-connect>1</burst-on-connect>
        <!-- same as burst-on-connect, but this allows for being more
             specific on how much to burst. Most people won't need to
             change from the default 64k. Applies to all mountpoints  -->
        <burst-size>65535</burst-size>
    </limits>

    <authentication>
        <!-- Sources log in with username 'source' -->
        <source-password>stream2day</source-password>
        <!-- Relays log in username 'relay' -->
        <relay-password>stream2day</relay-password>

        <!-- Admin logs in with the username given below -->
        <admin-user>admin</admin-user>
        <admin-password>2b|~2b</admin-password>
    </authentication>

    <!-- Uncomment this if you want directory listings -->
    <!--
    <directory>
        <yp-url-timeout>15</yp-url-timeout>
        <yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
    </directory>
    <directory>
        <yp-url-timeout>15</yp-url-timeout>
        <yp-url>http://www.oddsock.org/cgi-bin/yp-cgi</yp-url>
    </directory>
     -->

    <!-- This is the hostname other people will use to connect to your server.
    It affects mainly the urls generated by Icecast for playlists and yp
    listings. -->
    <hostname>192.168.0.103</hostname>

    <!-- You can use these two if you only want a single listener -->
    <!--<port>8000</port> -->
    <!--<bind-address>127.0.0.1</bind-address>-->

    <!-- You may have multiple <listener> elements -->
    <listen-socket>
        <port>8000</port>
        <!-- <bind-address>127.0.0.1</bind-address> -->
    </listen-socket>
    <!--
    <listen-socket>
        <port>8001</port>
    </listen-socket>
    -->

    <!--<master-server>127.0.0.1</master-server>-->
    <!--<master-server-port>8001</master-server-port>-->
    <!--<master-update-interval>120</master-update-interval>-->
    <!--<master-password>hackme</master-password>-->

    <!-- setting this makes all relays on-demand unless overridden, this is
         useful for master relays which do not have <relay> definitions here.
         The default is 0 -->
    <!--<relays-on-demand>1</relays-on-demand>-->

    <!--
    <relay>
        <server>127.0.0.1</server>
        <port>8001</port>
        <mount>/example.ogg</mount>
        <local-mount>/different.ogg</local-mount>
        <on-demand>0</on-demand>

        <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
    </relay>
    -->

    <!-- Only define a <mount> section if you want to use advanced options,
         like alternative usernames or passwords
    <mount>
        <mount-name>/example-complex.ogg</mount-name>

        <username>othersource</username>
        <password>hackmemore</password>

        <max-listeners>1</max-listeners>
        <dump-file>/tmp/dump-example1.ogg</dump-file>
        <burst-size>65536</burst-size>
        <fallback-mount>/example2.ogg</fallback-mount>
        <fallback-override>1</fallback-override>
        <fallback-when-full>1</fallback-when-full>
        <intro>/example_intro.ogg</intro>
        <hidden>1</hidden>
        <no-yp>1</no-yp>
        <authentication type="htpasswd">
                <option name="filename" value="myauth"/>
                <option name="allow_duplicate_users" value="0"/>
        </authentication>
        <on-connect>/home/icecast/bin/stream-start</on-connect>
        <on-disconnect>/home/icecast/bin/stream-stop</on-disconnect>
    </mount>

    <mount>
        <mount-name>/auth_example.ogg</mount-name>
        <authentication type="url">
            <option name="mount_add"       value="http://myauthserver.net/notify_mount.php"/>
            <option name="mount_remove"    value="http://myauthserver.net/notify_mount.php"/>
            <option name="listener_add"    value="http://myauthserver.net/notify_listener.php"/>
            <option name="listener_remove" value="http://myauthserver.net/notify_listener.php"/>
        </authentication>
    </mount>

    -->

    <fileserve>1</fileserve>

    <!-- set the mountpoint for a shoutcast source to use, the default if not
         specified is /stream but you can change it here if an alternative is
         wanted or an extension is required
    <shoutcast-mount>/live.nsv</shoutcast-mount>
    -->

    <paths>
                <!-- basedir is only used if chroot is enabled -->
        <basedir>./</basedir>

        <!-- Note that if <chroot> is turned on below, these paths must both
             be relative to the new root, not the original root -->
        <logdir>./logs</logdir>
        <webroot>./web</webroot>
        <adminroot>./admin</adminroot>
        <!-- <pidfile>./icecast.pid</pidfile> -->

        <!-- Aliases: treat requests for 'source' path as being for 'dest' path
             May be made specific to a port or bound address using the "port"
             and "bind-address" attributes.
          -->
        <!--
        <alias source="/foo" dest="/bar"/>
          -->
        <!-- Aliases: can also be used for simple redirections as well,
             this example will redirect all requests for http://server:port/ to
             the status page
          -->
        <alias source="/" dest="/status.xsl"/>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <!-- <playlistlog>playlist.log</playlistlog> -->
      <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
      <logsize>10000</logsize> <!-- Max size of a logfile -->
        <!-- If logarchive is enabled (1), then when logsize is reached
             the logfile will be moved to [error|access|playlist].log.DATESTAMP,
             otherwise it will be moved to [error|access|playlist].log.old.
             Default is non-archive mode (i.e. overwrite)
        -->
        <!-- <logarchive>1</logarchive> -->
    </logging>

    <security>
        <chroot>0</chroot>
        <!--
        <changeowner>
            <user>nobody</user>
            <group>nogroup</group>
        </changeowner>
        -->
    </security>
</icecast>


216.82.50.224 - - [08/Nov/2009:11:26:08 -0800] "GET /stream/7.html HTTP/1.0" 404 106 "-" "XML Getter (Mozilla Compatible)" 0
24.83.23.157 - - [08/Nov/2009:11:27:04 -0800] "GET /quant.ogg HTTP/1.1" 200 413945 "-" "FMOD/3.74" 45

[2009-11-08  11:26:00] INFO main/main.c Icecast 2.3.1 server started
[2009-11-08  11:26:00] INFO yp/yp.c YP update thread started
[2009-11-08  11:26:00] INFO auth/auth.c Authentication thread started
[2009-11-08  11:26:08] INFO fserve/fserve.c checking for file /stream/7.html (./web/stream/7.html)
[2009-11-08  11:26:08] WARN fserve/fserve.c req for file "./web/stream/7.html" No such file or directory
[2009-11-08  11:26:10] INFO connection/connection.c Source logging in at mountpoint "/quant.ogg"
[2009-11-08  11:26:11] INFO format-vorbis/format_vorbis.c seen initial vorbis header
[2009-11-08  11:26:11] INFO format-vorbis/format_vorbis.c seen initial vorbis header
[2009-11-08  11:26:19] INFO source/source.c listener count on /quant.ogg now 1
[2009-11-08  11:27:04] INFO source/source.c listener count on /quant.ogg now 0
[2009-11-08  11:27:06] INFO source/source.c listener count on /quant.ogg now 1
[2009-11-08  11:29:49] INFO format-vorbis/format_vorbis.c seen initial vorbis header
[2009-11-08  11:34:41] INFO format-vorbis/format_vorbis.c seen initial vorbis header

_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Karl Heyes]

On 08/11/09 19:35, Eric Kolotyluk wrote:

> As far as I can tell, the access.log file shows no indication of
> listener activity, at least I can see no correspondence of log lines
> that match when the listeners appear in the error.log file. Is there a
> way to increase the logging level in this file? Should I be able to see
> listeners attaching in this file?
>
> In the error.log file I can see no indication of a two listeners
> attempting to connect. I can see where listener-a connects, but there is
> no indication of the listener-b attempting to connect. I can see
> listener-a disconnect, and then I can see listener-b connect, but there
> is no indication of listener-a trying to reconnect. It is possible that
> after listener-a connects, Icecast is not event getting a connect
> message from listener-b because something else is blocking it out
> (Windows or the router)? Maybe I need to install a packet listener on my
> system an watch the ethernet traffic?

I would agree with that

> Possible problems are
>
> 1. My router. But I think not because the same router supports multiple
> listeners with my old computer, and both computers are connected to the
> same router.

very unlikely to be the router.

> 2. My new computer is Windows 7 64-bit Ultimate RTM (with two ethernet
> connections). My old computer is Windows XP (with one ethernet
> connection). It would help if someone else could tell me if they have
> Icecast working correctly (or not) on Windows 7.

seeing that win7 is the new component in the chain, I would say this is
very likely to be the cause. Probably down to the win7 firewall or TCP
stack limiting connections, in theory a packet sniffer would still see
the packets getting to the win7 network interface but would drop the
connection immediately.

karl.

_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast