Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:49Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/866buildm3u is checking for a source before returning.. Not good for file serving2018-03-06T12:49:49ZGitlab Botbuildm3u is checking for a source before returning.. Not good for file serving"can you report that on bugs.xiph.org, the buildm3u is checking for a source before returning and as you say, that doesn't work for files.
karl."
buildm3u is always checking for a source before attempting to authenticate a stream. ..."can you report that on bugs.xiph.org, the buildm3u is checking for a source before returning and as you say, that doesn't work for files.
karl."
buildm3u is always checking for a source before attempting to authenticate a stream. This does not work for file serving.
Are there any thoughts to create an option like buildm3u for file serving?
Was attempting to create a mount to a file and alias it to its directory. Then in the mount, use the url authenticator to protect it.
<mount>
<mount-name>/song.ogg</mount-name>
<authentication type="url">
<option name="listener_add" value="http://myserv/auth/action.php"/>
<option name="listener_remove" value="http://myserv/auth/action.php"/>
</authentication>
</mount>
<paths>
<alias source="/song.ogg" dest="/dir/dir/song.ogg"/>
</paths>
I use the following to auth a stream when I have a user currently logged into my site. http://myserv:8000/admin/buildm3u?username=test&password=test2&mount=/song.ogg
but, since a fileserve mount is not a true source, this will not work for serving files.
error_log:
[2006-03-11 15:49:08] WARN admin/admin_handle_request Admin command buildm3u on non-existent source /song.ogg
65.67.62.64 - - [11/Mar/2006:15:49:08 -0600] "GET /admin/buildm3u HTTP/1.1" 400 83 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)" 0
Any way to auth file server requests with passing username and password information without requiring user to type it in on the player pop-up?
thanks,
-matt
Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/821Icecast connection limit reached.2018-03-06T12:49:49ZhanIcecast connection limit reached.When I use icecast-2.2.0 it works fine, when I run icecast-2.3.0 or 2.3.1 I get that errormessage whenever I try to connect.
I think it is related to this commit: http:...When I use icecast-2.2.0 it works fine, when I run icecast-2.3.0 or 2.3.1 I get that errormessage whenever I try to connect.
I think it is related to this commit: http://lists.xiph.org/pipermail/commits/2005-April/007172.html
I'm running icecast-2.3.1 on OpenBSD with these patches: http://www.openbsd.org/cgi-bin/cvsweb/ports/net/icecast/patches/
```
<icecast>
<limits>
<clients>1</clients>
<sources>2</sources>
<threadpool>5</threadpool>
<queue-size>102400</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>65535</burst-size>
</limits>
<authentication>
<source-password>secret</source-password>
</authentication>
<hostname>boetes.org</hostname>
<port>8000</port>
<bind-address>192.168.1.68</bind-address>
<listen-socket>
<port>7777</port>
<bind-address>172.16.11.1</bind-address>
</listen-socket>
<fileserve>0</fileserve>
<paths>
<basedir>/var/icecast</basedir>
<logdir>/log</logdir>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel>
</logging>
<security>
<chroot>1</chroot>
<changeowner>
<user>_icecast</user>
<group>bot</group>
</changeowner>
</security>
</icecast>
```Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/802Icecast mounts and Sam 32018-03-06T12:49:49ZDavidIcecast mounts and Sam 3using Sam 3 encoder does not recoginze the username and password for authenticating source when mount is specified in Icecast config. So in effect I can use Sam and Icecast. Only if I don't declare a mount in the icecast config file. Ice...using Sam 3 encoder does not recoginze the username and password for authenticating source when mount is specified in Icecast config. So in effect I can use Sam and Icecast. Only if I don't declare a mount in the icecast config file. Icecast will automatically declare whatever Sam shows and broadcast.
This would normally be ok if I was just streaming 1 broadcast, but I'm trying to manage mutiple broadcast and thier max listener capacity and stream quality.
Is there a workaround for this without declaring a mount? Icecast seems to be declaring mounts on the fly from Sam3, but like I said it leaves connections as unlimited....
Can you help fix this?Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/801Icecast server source details max-listeners2018-03-06T12:49:49ZDavidIcecast server source details max-listenersSpecified on the mount the number of max listeners to 1. Tried connecting form 2 different sources and it still allowed the 2nd connection. In addtion the sever details shows max_listeners "unlimited" instead of 1Specified on the mount the number of max listeners to 1. Tried connecting form 2 different sources and it still allowed the 2nd connection. In addtion the sever details shows max_listeners "unlimited" instead of 1Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/800URL listener authenticator2018-03-06T12:49:49ZDavidURL listener authenticatorYour URL auth is not working properly I used the examples in the domumentation altering my url and it does not auth. it just connects to the stream...In addtion with the basic orginal file admin control panel does not show the red key...
Your URL auth is not working properly I used the examples in the domumentation altering my url and it does not auth. it just connects to the stream...In addtion with the basic orginal file admin control panel does not show the red key...
Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/775default log level should be lower2018-03-06T12:49:49ZGhost Userdefault log level should be lowerIcecast 2.3.1 shipped with the default loglevel of 4, which generates rather more lines than one would want in a production environment. I suggest that this default be changed to 2 or 3.Icecast 2.3.1 shipped with the default loglevel of 4, which generates rather more lines than one would want in a production environment. I suggest that this default be changed to 2 or 3.Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/774YP data submitted even when source cannot connect2018-03-06T12:49:49Zchris.aretiYP data submitted even when source cannot connectHi,
I'm using 2.3.0 but as I didn't see it as a bugfix on the list, I'm presuming it remains the same in 2.3.1..
I have icecast set to not allow people to take over source control if someone's connected already, however due to necessit...Hi,
I'm using 2.3.0 but as I didn't see it as a bugfix on the list, I'm presuming it remains the same in 2.3.1..
I have icecast set to not allow people to take over source control if someone's connected already, however due to necessity when some people kill the connected source and broadcast - the main broadcast server still attempts to connect to the source every 15 seconds. This means that when the DJ has finished their set, then simply disconnect and 24 hour playout comes back online.
However, I've noticed with 2.3.0 that even though the broadcast server gets a disconnected error message, the metadata the broadcast server generates whilst the other source is on air manages to update and overwrite that which the current source connection is providing.
In short, metadata from a connecting client (who cannot connect because the source is in use by another client) still manages to be accepted by icecast and updated on the stream.. meaning that the two clients are constantly fighting to keep metadata with that of the current source.
Any help would be much appreciated!
Thanks,
Chris.Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/732hi-world cup2018-03-06T12:49:49Zsci-fihi-world cupHi,
Clients can't connect to our system. I compiled icecast 2.3.0 from svn, tried the official 2.3.0 src dist, went back to 2.3.0rc3, to no avail.
We're still running MacOSX 10.3.9 aka Panther due to issues with 10.4.x aka Tiger. I c...Hi,
Clients can't connect to our system. I compiled icecast 2.3.0 from svn, tried the official 2.3.0 src dist, went back to 2.3.0rc3, to no avail.
We're still running MacOSX 10.3.9 aka Panther due to issues with 10.4.x aka Tiger. I can't prove it but the update from 10.3.8 to 10.3.9+securityfixes might have something to do with it, but we're stuck with 10.3.9 for the time being. I do remember when we had 10.3.8, we were successfully using icecast 2.2.0 and 2.3.0rc1 when it came out (both compiled myself with similar gcc/ld settings).
We're listed on the YPs as SciFi.homeip.net on Friday and Saturday nights U.S. time; maybe we can schedule some test time per feedback from this ticket.
We're running icecast by relaying the stream from localhost:32720 which is shoutcast 1.9.6b (a fix for MacOSX users which is the port number going negative when set above 32767). btw We use high port numbers to skirt around ISP possibly blocking the usual ones, and we have net.sysctl settings to make sure other apps don't use those ranges up there.
Listeners to our shoutcast streams are working, as are p2p-radio and Peercast, which I also compiled myself from cvs/svn as appropriate. Every netcast app works *but* icecast for the time being, and I can't figure out why.
There is _no_ firewall (software, hardware, or otherwise) between the Mac and the cable modem.
Here is a snip from our icecast error.log for tonight's netcast:
```
[...]
[2005-11-05 19:15:20] INFO main/main Icecast 2.3.0 server started
[2005-11-05 19:15:20] INFO yp/yp_recheck_config Adding new YP server "http://dir.xiph.org/cgi-bin/yp-cgi" (timeout 15s, default interval 30s)
[2005-11-05 19:15:20] INFO yp/yp_recheck_config Adding new YP server "http://www.steamcast.com/sbin/yp.php" (timeout 15s, default interval 30s)
[2005-11-05 19:15:20] INFO yp/yp_update_thread YP update thread started
[2005-11-05 19:15:20] INFO auth/auth_run_thread Authentication thread started
[2005-11-05 19:15:21] INFO slave/start_relay_stream Starting relayed source at mountpoint "/"
[2005-11-05 19:22:05] WARN client/client_read_bytes source connection has died
[2005-11-05 22:57:26] WARN client/client_read_bytes source connection has died
[2005-11-05 22:57:30] WARN client/client_read_bytes source connection has died
[2005-11-05 23:37:05] WARN client/client_read_bytes source connection has died
[...]
```
The above is a mix of clients "out there" and myself running iTunes on the localhost. Nothing can get hold of the stream.
There is nothing in the access.log for icecast, so these clients didn't even get the very beginning icy-html stuff.
We have relays-on-demand turned off; I don't think turning it on made any difference.
The shoutcast server did see the initial connection; here is that snip from its log:
```
<11/05/05@19:15:21> [dest: 127.0.0.1] starting stream (UID: 4)[L: 3]{A: Icecast 2.3.0}(P: 1)
```
This initial connection didn't use to work either. I had to patch the icecast230 src in the following manner to get this much working:
```
---cut-here---
--- src/slave.c_orig 2005-09-30 14:39:08 -0500
+++ src/slave.c 2005-09-30 14:39:26 -0500
@@ -174,7 +174,7 @@
{
char *auth_header;
- streamsock = sock_connect_wto (relay->server, relay->port, 30);
+ streamsock = sock_connect_wto (relay->server, relay->port, 0);
if (streamsock == SOCK_ERROR)
{
WARN3("Failed to relay stream from master server, couldn't connect to http://%s:%d%s",
---cut-here---
```
fwiw I tried this patch to get the client streams working but to no avail:
```
---cut-here---
--- src/net/sock.c_orig 2005-09-30 21:36:15 -0500
+++ src/net/sock.c 2005-10-01 15:37:40 -0500
@@ -433,7 +433,7 @@
if (!buff) return 0;
if (len <= 0) return 0;
- return recv(sock, buff, len, 0);
+ return recv(sock, buff, len, MSG_WAITALL);
}
/* sock_read_line
---cut-here---
```
So there's a clue to get the client streams working, but I'm unable to figure it out further. :(
Here is our full icecast.xml (obfuscating the passwords of course ;) ):
```
--- icecast.xml ---
<icecast>
<limits>
<clients>3</clients>
<sources>1</sources>
<threadpool>25</threadpool>
<queue-size>1048576</queue-size>
<client-timeout>65535</client-timeout>
<header-timeout>65535</header-timeout>
<source-timeout>65535</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>131072</burst-size>
</limits>
<authentication>
<!-- Sources log in with username 'source' -->
<source-password>(duh!)</source-password>
<!-- Relays log in username 'relay' -->
<relay-password></relay-password>
<!-- Admin logs in with the username given below -->
<admin-user>admin</admin-user>
<admin-password>(duh!)</admin-password>
</authentication>
<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.steamcast.com/sbin/yp.php</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 manufactured mount name for your shoutcast
compatible stream. Since the shoutcast DSP (and NSV encoder)
cannot specify a mountpoint, you must enter it here -->
<shoutcast-mount>/stream</shoutcast-mount>
<!-- 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>SciFi.homeip.net</hostname>
<!-- You MUST define 2 ports, port and port +1,
for Shoutcast-compatibility -->
<listen-socket>
<!-- Configure the shoutcast DSP with *this* port
the shoutcast DSP actually will connect the
encoder to this port + 1 -->
<port>32710</port>
</listen-socket>
<listen-socket>
<!-- This port *must* be one larger than the one defined
above and defined as 'shoutcast-compat' -->
<port>32711</port>
<shoutcast-compat>1</shoutcast-compat>
</listen-socket>
<relays-on-demand>0</relays-on-demand>
<relay>
<server>127.0.0.1</server>
<port>32720</port>
<mount>/</mount>
<local-mount>/</local-mount>
<on-demand>0</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
<!-- Only define a <mount> section if you want to use advanced options,
like alternative usernames or passwords
-->
<mount>
<mount-name>/</mount-name>
<max-listeners>2</max-listeners>
<no-yp>0</no-yp>
<hidden>0</hidden>
</mount>
<fileserve>1</fileserve>
<paths>
<!-- basedir is only used if chroot is enabled -->
<basedir>/usr/local/share/icecast</basedir>
<!-- Note that if <chroot> is turned on below, these paths must both
be relative to the new root, not the original root -->
<logdir>.</logdir>
<webroot>/usr/local/share/icecast/web</webroot>
<adminroot>/usr/local/share/icecast/admin</adminroot>
<pidfile>/var/run/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"/>
-->
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
</logging>
<!--
<security>
<chroot>0</chroot>
<changeowner>
<user>nobody</user>
<group>nogroup</group>
</changeowner>
</security>
-->
</icecast>
--- end icecast.xml ---
```
Yes the icecast admin can sign-on and look at all the current settings etc. But no clients can get the stream.
Any help, ideas, tests, etc. I would be greatful.
Thank you.
Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/708Source / mountpoint from SQL / LDAP / flat file (?)2018-03-06T12:49:49ZkiwiSource / mountpoint from SQL / LDAP / flat file (?)Hi there,
I'd really like to have source authentication (eg mount point and password) from a DB / LDAP source instead of using static entries in XML files.
Even the simple way to have include files to add multiples mount point password...Hi there,
I'd really like to have source authentication (eg mount point and password) from a DB / LDAP source instead of using static entries in XML files.
Even the simple way to have include files to add multiples mount point password should be very appreciated.
Can it donc in next icecast version ?
Thanks !
/XavierIcecast 2.3Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/707[PATCH] Segfault in src/admin.c2018-03-06T12:49:49Zmartin[PATCH] Segfault in src/admin.cMy Icecast 2.3.0.rc2 was segfaulting, when listmounts.xsl was requested, and there were mounts with fallback configured, so I have done little debugging. The "source->client" object must exist before we can check "source->client->con", s...My Icecast 2.3.0.rc2 was segfaulting, when listmounts.xsl was requested, and there were mounts with fallback configured, so I have done little debugging. The "source->client" object must exist before we can check "source->client->con", see patch. Please take a look at my http-auth-logging patch, too (Ticket #706). Thanks.
```
--- admin.c.orig Sun Sep 11 22:57:35 2005
+++ admin.c Sun Sep 11 23:18:09 2005
@@ -252,7 +252,7 @@
if (source->running)
{
- if (source->client->con)
+ if (source->client && source->client->con)
{
snprintf (buf, sizeof(buf), "%lu",
(unsigned long)(now - source->con->con_time));
```
Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/705Bug in auth.c (version 2.3.0.rc2)2018-03-06T12:49:49ZmartinBug in auth.c (version 2.3.0.rc2)The function check_duplicate_logins in auth.c (2.3.0.rc2, lines 225-266 ) contains a
bug. The "client" object passed to the function gets overwritten inside
it, and a the comparsion "strcmp (client->username, client->username) ==
0" alwa...The function check_duplicate_logins in auth.c (2.3.0.rc2, lines 225-266 ) contains a
bug. The "client" object passed to the function gets overwritten inside
it, and a the comparsion "strcmp (client->username, client->username) ==
0" always returns zero, so any username is always considered duplicate.
Patch suggestion:
```
--- src/auth.c.orig Sat Sep 10 16:44:43 2005
+++ src/auth.c Sat Sep 10 17:19:28 2005
@@ -238,8 +238,8 @@
node = avl_get_first (source->client_tree);
while (node)
{
- client_t *client = (client_t *)node->key;
- if (client->username && strcmp (client->username, client->username) == 0)
+ client_t *existing_client = (client_t *)node->key;
+ if (existing_client->username && strcmp (existing_client->username, client->username) == 0)
{
avl_tree_unlock (source->client_tree);
return 0;
@@ -252,8 +252,8 @@
node = avl_get_first (source->pending_tree);
while (node)
{
- client_t *client = (client_t *)node->key;
- if (client->username && strcmp (client->username, client->username) == 0)
+ client_t *existing_client = (client_t *)node->key;
+ if (existing_client->username && strcmp (existing_client->username, client->username) == 0)
{
avl_tree_unlock (source->pending_tree);
return 0;
```Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/700crash when start manage auth2018-03-06T12:50:21Zlanta1crash when start manage auth[2005-09-02 23:41:16] DBUG stats/stats.c update node sources (1)
[2005-09-02 23:41:16] DBUG stats/stats.c new source stat /stream
[2005-09-02 23:41:16] DBUG stats/stats.c new node public (1)
[2005-09-02 23:41:16] DBUG stats/stats.c n...[2005-09-02 23:41:16] DBUG stats/stats.c update node sources (1)
[2005-09-02 23:41:16] DBUG stats/stats.c new source stat /stream
[2005-09-02 23:41:16] DBUG stats/stats.c new node public (1)
[2005-09-02 23:41:16] DBUG stats/stats.c new node server_name (SYSTEM S70 VAERMLAND)
[2005-09-02 23:41:16] DBUG stats/stats.c new node server_description (Unspecified description)
[2005-09-02 23:41:16] DBUG stats/stats.c new node server_url (http://dir.xiph.org/)
[2005-09-02 23:41:16] DBUG stats/stats.c new node genre (Scanner)
[2005-09-02 23:41:16] DBUG stats/stats.c new node bitrate (24)
[2005-09-02 23:41:16] DBUG stats/stats.c new node server_type (audio/mpeg)
[2005-09-02 23:41:16] DBUG stats/stats.c new node authenticator (htpasswd)
[2005-09-02 23:41:16] DBUG stats/stats.c new node max_listeners (unlimited)
[2005-09-02 23:41:16] DBUG stats/stats.c new node source_ip (127.0.0.1)
[2005-09-02 23:41:16] DBUG stats/stats.c update node source_client_connections (1)
[2005-09-02 23:41:16] DBUG stats/stats.c new node listeners (0)
[2005-09-02 23:41:16] DBUG stats/stats.c new node listenurl (http://213.114.105.49:8000/stream)
[2005-09-02 23:41:16] DBUG stats/stats.c new node listener_peak (0)
[2005-09-02 23:41:16] DBUG stats/stats.c update node source_total_connections (1)
[2005-09-02 23:41:16] DBUG stats/stats.c new node slow_listeners (0)
[2005-09-02 23:41:16] DBUG stats/stats.c update node listeners (0)
[2005-09-02 23:41:16] DBUG stats/stats.c update node listener_peak (0)
[2005-09-02 23:41:16] DBUG stats/stats.c new node stream_start (Fri, 02 Sep 2005 23:41:16 Västeuropa, sommartid)
[2005-09-02 23:41:16] DBUG stats/stats.c new node total_bytes_read (0)
[2005-09-02 23:41:16] DBUG stats/stats.c new node total_bytes_sent (0)
[2005-09-02 23:41:17] DBUG slave/slave.c checking master stream list
[2005-09-02 23:41:21] DBUG stats/stats.c update node total_bytes_read (13636)
[2005-09-02 23:41:21] DBUG stats/stats.c update node total_bytes_sent (0)
[2005-09-02 23:41:21] DBUG yp/yp.c server touch interval is 60
[2005-09-02 23:41:21] DBUG yp/yp.c YP add at http://dir.xiph.org/cgi-bin/yp-cgi succeeded
[2005-09-02 23:41:22] DBUG stats/stats.c update node clients (2)
[2005-09-02 23:41:22] DBUG stats/stats.c update node connections (2)
[2005-09-02 23:41:22] DBUG admin/admin.c Admin request (/admin/manageauth.xsl)
[2005-09-02 23:41:22] DBUG admin/admin.c Got command (manageauth.xsl)
[2005-09-02 23:41:22] WARN admin/admin.c Admin command manageauth.xsl on non-existent source /stream.m3u
[2005-09-02 23:41:22] DBUG fserve/fserve.c Adding client to file serving engine
[2005-09-02 23:41:23] DBUG stats/stats.c update node client_connections (1)
[2005-09-02 23:41:23] DBUG stats/stats.c update node clients (1)
[2005-09-02 23:41:24] DBUG stats/stats.c update node clients (2)
[2005-09-02 23:41:24] DBUG stats/stats.c update node connections (3)
[2005-09-02 23:41:24] DBUG admin/admin.c Admin request (/admin/manageauth.xsl)
[2005-09-02 23:41:24] DBUG admin/admin.c Got command (manageauth.xsl)
[2005-09-02 23:41:24] WARN admin/admin.c Admin command manageauth.xsl on non-existent source /stream.m3u
[2005-09-02 23:41:24] DBUG fserve/fserve.c Adding client to file serving engine
[2005-09-02 23:41:25] DBUG stats/stats.c update node client_connections (2)
[2005-09-02 23:41:25] DBUG stats/stats.c update node clients (1)
[2005-09-02 23:41:26] DBUG stats/stats.c update node total_bytes_read (28607)
[2005-09-02 23:41:26] DBUG stats/stats.c update node total_bytes_sent (0)
[2005-09-02 23:41:26] DBUG yp/yp.c YP touch at http://dir.xiph.org/cgi-bin/yp-cgi succeeded
[2005-09-02 23:41:31] DBUG stats/stats.c update node total_bytes_read (43400)
[2005-09-02 23:41:31] DBUG stats/stats.c update node total_bytes_sent (0)
[2005-09-02 23:41:32] DBUG admin/admin.c Admin request (/admin/manageauth.xsl)
[2005-09-02 23:41:32] DBUG admin/admin.c Got command (manageauth.xsl)
[2005-09-02 23:41:32] INFO admin/admin.c Received admin command manageauth.xsl on mount "/stream"
[2005-09-02 23:41:32] WARN auth_htpasswd/auth_htpasswd.c failed to check status of myauth
[2005-09-02 23:41:32] DBUG stats/stats.c update node clients (2)
[2005-09-02 23:41:32] DBUG stats/stats.c update node connections (4)
[2005-09-02 23:41:32] DBUG stats/stats.c update node client_connections (3)
[2005-09-02 23:41:36] DBUG stats/stats.c update node total_bytes_read (58545)
[2005-09-02 23:41:36] DBUG stats/stats.c update node total_bytes_sent (0)
Icecast 2.3Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/689YP updates should be serialised per YP directory to isolate problem servers2018-03-06T12:50:21ZGitlab BotYP updates should be serialised per YP directory to isolate problem serversYP updates (touches) for all mounts and YP directories are performed in series. If a YP server is slow to respond, e.g. 10 seconds, this may cause YP listings to not be maintained properly. E.g., 36 mounts with an average response time...YP updates (touches) for all mounts and YP directories are performed in series. If a YP server is slow to respond, e.g. 10 seconds, this may cause YP listings to not be maintained properly. E.g., 36 mounts with an average response time of 10 seconds per update will take 6 minutes per update cycle, while the YP directory may expect updates every two to five minutes. All of the YP directories will be affected by one slow YP directory in the configuration.
YP servers should be isolated, with YP updates for multiple YP directories performed in parallel (a separate series for each YP server).Icecast 2.3Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/661Display source IP for earch mountpoint in admin/stats.xsl2018-03-06T12:50:21ZGitlab BotDisplay source IP for earch mountpoint in admin/stats.xslIt would be nice to see source IP-address in stats.xsl page for each mounpoint. Nowdays if I like to find out who is sending stream to mountpoint, I have to dig it out with ugly shell command: cat /var/log/icecast/access.log | grep SOURC...It would be nice to see source IP-address in stats.xsl page for each mounpoint. Nowdays if I like to find out who is sending stream to mountpoint, I have to dig it out with ugly shell command: cat /var/log/icecast/access.log | grep SOURCE | awk '{ printf $1 " " $7 "\n" }' | sort | uniqIcecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/642Fallback overrides when it shouldn't2021-01-29T10:17:57ZGitlab BotFallback overrides when it shouldn'tI have a server with two mounts which have the same fallback mount.
Actually, I have three mounts, with one having a second as its fallback
and that second having the common fallback. But you get the idea.
All these mounts have fallbac...I have a server with two mounts which have the same fallback mount.
Actually, I have three mounts, with one having a second as its fallback
and that second having the common fallback. But you get the idea.
All these mounts have fallback-override set.
The problem is that if I connect to any of the mounts for which the
fallback mount is configured, all mounts currently falling back to that
mount will be pulled forward to the connecting stream, not just listeners
who tuned in via the connected mount.
Example. A and B are configured to fall back to C. Listeners tune into
both A and B when neither is connected and drop through to C. A source
connects to B. All listeners through both A and B are pulled forward to B.
This only affects listeners tuned in at the time the source connects.
Using the above example, anyone tuning into A after B connects will still
get C.
This is using Icecast 2.2 compiled from source on Debian 3.0.Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/632Incorrect Base64 decoder in utils (missing '2018-03-06T12:50:22ZGitlab BotIncorrect Base64 decoder in utils (missing '*Base64 utils. Encode is ok, but decode? '=' is missed, so, VLC, that
contains correct base64 encoder, produces '=' at the end of the string.
We need to pacth that case in decoder:
char *util_base64_decode(unsigned char *input)
{
...*Base64 utils. Encode is ok, but decode? '=' is missed, so, VLC, that
contains correct base64 encoder, produces '=' at the end of the string.
We need to pacth that case in decoder:
char *util_base64_decode(unsigned char *input)
{
int len = strlen(input);
char *out = malloc(len*3/4 + 5);
char *result = out;
signed char vals[4];
while(len > 0) {
if(len < 4 && *input != '=')
{
free(result);
return NULL; /* Invalid Base64 data */
} else if (*input == '=') break;
Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/631Authentication fails: authentication file location undefined2018-03-06T12:50:21ZGitlab BotAuthentication fails: authentication file location undefinedAuthentication requires a file (mypath in example), that resides in unknown
location (current dir? which one?). So, look at the string, when we edit the file:
(in function static auth_result htpasswd_deleteuser(auth_t *auth, const
char *...Authentication requires a file (mypath in example), that resides in unknown
location (current dir? which one?). So, look at the string, when we edit the file:
(in function static auth_result htpasswd_deleteuser(auth_t *auth, const
char *username)):
sprintf(tmpfile, ".%s.tmp", state->filename);
we are adding a dot. it is not correct, because location of the file is
not known. if I put the full path, I can get strange result, yeh?
Icecast 2.3Ed "oddsock" ZaleskiEd "oddsock" Zaleskihttps://gitlab.xiph.org/xiph/icecast-server/-/issues/620Update Shoutcast Directory...2018-03-06T12:50:21ZIan PulverUpdate Shoutcast Directory...Why don't we enable Icecast users who are streaming MP3 to list themselves in the Shoutcast directory? Is this good or bad behaviour?
It'd be great in that the Shoutcast directory gets a lot more traffic than the XIPH one, so it supp...Why don't we enable Icecast users who are streaming MP3 to list themselves in the Shoutcast directory? Is this good or bad behaviour?
It'd be great in that the Shoutcast directory gets a lot more traffic than the XIPH one, so it supports the goal of Broadcasters to reach as wide of an audience as possible. Not so great in that it is arguably bad behaviour and we're taking advantage of AOL/Nullsoft.
It is true however that any WinAmp user (at least after 3.x) will be able to connect to the Ogg or MP3 streams of Icecast servers, so that's not a limitation.
One thing's for sure is it'll draw a lot more traffic to IceCasters and that's always good.
-Ian.Icecast 2.3Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/619Icecast Can't Define its own YP Listing Parameters...2018-03-06T12:50:21ZIan PulverIcecast Can't Define its own YP Listing Parameters...Not everyone encodes for streaming using Ices. :-)
For those of us using realtime hardware encoders, we're unable to list in the Icecast YP under anything meaningful because those encoders do not populate the fields "yp->server_name, yp...Not everyone encodes for streaming using Ices. :-)
For those of us using realtime hardware encoders, we're unable to list in the Icecast YP under anything meaningful because those encoders do not populate the fields "yp->server_name, yp->server_genre, yp->cluster_password, yp->server_desc, yp->url, yp->listen_url, yp->server_type, yp->subtype, yp->bitrate, yp->audio_info". A simple fix would be to allow Icecast to read some/all of these from the config file at run-time so they can be hard-coded within Icecast. Ideally this could be a per-stream configuration rather than global, which would provide true transparency of the server and allow it to host multiple distinct genres, etc..
For reference, check out this discussion from the mailing list:
http://lists.xiph.org/pipermail/icecast/2005-February/008564.html
http://lists.xiph.org/pipermail/icecast/2005-February/008538.html
This small feature would be tremendously influential in driving more traffic to icecast sites currently experiencing this limitation.. and will probably influence the ability to list in other directories such as YahoO!, iTunes, etc.
Thanks guys..
-Ian.Icecast 2.3Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2486WIndows 32bit builds lead to connection-timout2024-01-20T23:52:33ZStephan JauernickWIndows 32bit builds lead to connection-timoutWe have not dug to deep into this yet.
It broke between 2.5b3 and current devel.
The server starts normally and all looks well, connections timeout.
Nothing is logged even with debugging.
phschafft has config.logs and config.hWe have not dug to deep into this yet.
It broke between 2.5b3 and current devel.
The server starts normally and all looks well, connections timeout.
Nothing is logged even with debugging.
phschafft has config.logs and config.hIcecast 2.5 rc1