Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:48Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1108icecast-2.3.1 fails to compile against curl-7.16.02018-03-06T12:49:48ZDanielicecast-2.3.1 fails to compile against curl-7.16.0Small bug report:
CURLOPT_PASSWDFUNCTION is a depreciated option ref:
curl.haxx.se/mail/lib-2003-10/0100.html
curl.haxx.se/mail/archive-2003-11/0001.html
They have finally removed it in curl-7.16.0.
Compile error as follows:
source='...Small bug report:
CURLOPT_PASSWDFUNCTION is a depreciated option ref:
curl.haxx.se/mail/lib-2003-10/0100.html
curl.haxx.se/mail/archive-2003-11/0001.html
They have finally removed it in curl-7.16.0.
Compile error as follows:
source='auth_url.c' object='auth_url.o' libtool=no \
depfile='.deps/auth_url.Po' tmpdepfile='.deps/auth_url.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -ffast-math -fsigned-char -I/usr/include/libxml2 -I/usr/include -pthread -march=athlon-xp -O2 -pipe -c
`test -f 'auth_url.c' || echo './'`auth_url.c
auth_url.c: In function `auth_get_url_auth':
auth_url.c:521: error: `CURLOPT_PASSWDFUNCTION' undeclared (first use in this
function)
auth_url.c:521: error: (Each undeclared identifier is reported only once
auth_url.c:521: error: for each function it appears in.)
make[3]: *** [auth_url.o] Error 1
make[3]: Leaving directory
`/var/tmp/portage/net-misc/icecast-2.3.1-r1/work/icecast-2.3.1/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/net-misc/icecast-2.3.1-r1/work/icecast-2.3.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/net-misc/icecast-2.3.1-r1/work/icecast-2.3.1'
make: *** [all] Error 2
also reported here;
bugs.gentoo.org/show_bug.cgi?id=157756
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/990make status.xsl to show only one mounpoint on demand.2018-03-06T12:49:48ZGitlab Botmake status.xsl to show only one mounpoint on demand.What I mean is something like:
/admin/listclients.xsl?mount=/station.ogg
So if you type:
/status.xsl?mount=/station.ogg
only the requested station is shown.
What I mean is something like:
/admin/listclients.xsl?mount=/station.ogg
So if you type:
/status.xsl?mount=/station.ogg
only the requested station is shown.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/944Icecast Crashes, Relay, metadata error2018-03-06T12:49:48ZGitlab BotIcecast Crashes, Relay, metadata error*<System>*
fc3
*<RPM's>*
libxml2-2.6.16-3
libxslt-1.1.11-1
curl-7.12.3-6.fc3
vorbis-tools-1.0.1-4
*<Source Tarballs/svn>*
Icecast-2.3.1 (svn, daily and tarball)
libshout-2.2.2 (source)
*<Results from command line>*
icecast -...*<System>*
fc3
*<RPM's>*
libxml2-2.6.16-3
libxslt-1.1.11-1
curl-7.12.3-6.fc3
vorbis-tools-1.0.1-4
*<Source Tarballs/svn>*
Icecast-2.3.1 (svn, daily and tarball)
libshout-2.2.2 (source)
*<Results from command line>*
icecast -c /usr/local/etc/icecast.xml
Changed groupid to 99.
Changed userid to 99.
Segmentation fault
*<Log>*
[2006-06-26 22:49:21] INFO fserve/fserve_client_create checking for file /corner_topleft.jpg (/usr/local/share/icecast/web/corner_topleft.jpg)
2006-06-26 22:49:21] INFO fserve/fserve_client_create checking for file /tunein.png (/usr/local/share/icecast/web/tunein.png)
[2006-06-26 22:49:21] INFO fserve/fserve_client_create checking for file /corner_bottomleft.jpg (/usr/local/share/icecast/web/corner_bottomleft.jpg)
[2006-06-26 22:49:22] EROR format-mp3/mp3_get_filter_meta Incorrect metadata format, ending stream
[2006-06-26 22:49:22] INFO source/source_shutdown Source "/ccbl-yarmouth" exiting
*<Conifg>*
<icecast>
<limits>
<clients>10000</clients>
<sources>50</sources>
<threadpool>8</threadpool>
<queue-size>524288</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>16000</burst-size> -->
</limits>
<suthenticatin> Ommitted <//authentication>
<listen-socket>
<port>8000</port>
<bind-address>10.100.100.10</bind-address>
</listen-socket>
<!-- ======================================================================================= -->
<master-server>10.100.200.10</master-server>
<master-server-port>8000</master-server-port>
<master-update-interval>60</master-update-interval>
<master-password>hackmaster</master-password>
<relays-on-demand>0</relays-on-demand>
<!-- ======================================================================================= -->
<fileserve>0</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>/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>/var/log/icecast</logdir>
<webroot>/usr/local/share/icecast/web</webroot>
<adminroot>/usr/local/share/icecast/admin</adminroot>
<pidfile>/usr/local/share/icecast/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 -->
</logging>
<security>
<chroot>0</chroot>
<!-- -->
<changeowner>
<user>nobody</user>
<group>nobody</group>
</changeowner>
<!-- -->
</security>
</icecast>
*<Incresaesd debug log level 4>*
these are the last few lines...
[2006-06-27 08:04:58] DBUG stats/modify_node_event update node total_bytes_read (37818)
[2006-06-27 08:04:58] DBUG stats/modify_node_event update node total_bytes_sent (0)
[2006-06-27 08:04:58] DBUG stats/modify_node_event update node total_bytes_read (36418)
[2006-06-27 08:04:58] DBUG stats/modify_node_event update node total_bytes_sent (0)
(Á▒FÂUòD*]B'»u3?«.T¾Sá}Yx_È0 @LÂO¢YÒ3/mD▒ZE«r!y£¢ÈýAR├»I¶ÿó(Ätcast metadata >Tr#9¤ÕÒÚ®T +«ÿó(ħ
Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/934[PATCH] Change configuration file in Win32 Service2018-03-06T12:49:48Zkiwicasio[PATCH] Change configuration file in Win32 ServiceI think it can be interesting to add possibiliy to change the location (and name) of configuration file wich is currently hardcoded in source code.
actually :
;-------------------------
int argc2 = 3;
char* argv2[3];
argv2[0] = ...I think it can be interesting to add possibiliy to change the location (and name) of configuration file wich is currently hardcoded in source code.
actually :
;-------------------------
int argc2 = 3;
char* argv2[3];
argv2[0] = "icecastService.exe";
argv2[1] = "-c";
argv2[2] = "icecast.xml";
int ret = mainService(argc2, (char **)argv2);
;-------------------------
I think this is not efficient :/
thank's in advance...https://gitlab.xiph.org/xiph/icecast-server/-/issues/920limit of bitrate for each mountpoint2023-01-03T19:11:52ZGitlab Botlimit of bitrate for each mountpointI would like to host an icecast server on my PC and my friends could broadcast with it. But I want to limit the bitrate. The DJ cannot broadcast at more than 128 kbps. How to limit the bitrate for every mountpoint ? or for all mountpoints ?I would like to host an icecast server on my PC and my friends could broadcast with it. But I want to limit the bitrate. The DJ cannot broadcast at more than 128 kbps. How to limit the bitrate for every mountpoint ? or for all mountpoints ?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/918typo in icecast README contained in icecast-2.3.1.tar.gz2018-03-06T12:49:49ZGitlab Bottypo in icecast README contained in icecast-2.3.1.tar.gzafter checking there's only one miss-spelling. =/ but patch nonethelessafter checking there's only one miss-spelling. =/ but patch nonethelessMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/902On-demand relay keeps relying after moving listeners.2018-03-06T12:49:49ZVladOn-demand relay keeps relying after moving listeners.On-demand relay keeps relaying after moving listeners to other mount point.
It keeps relaying with 0 listeners until "Kill Source" pressed.On-demand relay keeps relaying after moving listeners to other mount point.
It keeps relaying with 0 listeners until "Kill Source" pressed.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/887[PATCH] Multiple master servers for Icecast relay2018-06-15T21:32:52Zjcyr[PATCH] Multiple master servers for Icecast relayAt any time during the day there are 4 or 5 PCs or IP radios tuned to a common MP3 internet stream. In order to alleviate the traffic on my internet broadband link, I use an Icecast relay on my local network. It retrieves a single Shoutc...At any time during the day there are 4 or 5 PCs or IP radios tuned to a common MP3 internet stream. In order to alleviate the traffic on my internet broadband link, I use an Icecast relay on my local network. It retrieves a single Shoutcast stream from the Internet and all the local clients get their streams from it.
Icecast has worked very well in that capacity but has always suffered from a minor shortcoming. Many popular Shoutcast stations provide the same stream through multiple servers. Unfortunately, Icecast 2.3.1 only allows the specification of a single master server for each relay section. So if that master server refuses the connection there is no way to tell Icecast to try an alternate. I've coded a patch to the Icecast 2.3.1 source that allows the specification of multiple master servers. For each relay, Icecast will try each of the multiple servers that can now be specified till a connection is achieved.
The relay section in the icecast.xml file now looks like this:
<relay>
<servers>
<server>
<ip>64.236.34.196</ip>
<port>80</port>
</server>
<server>
<ip>64.236.34.4</ip>
<port>80</port>
</server>
</servers>
<mount>/stream/1048</mount>
<local-mount>/stream.mp3</local-mount>
<on-demand>0</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
If anybody's interested and in the spirit of open source development I've made the patch available as a contribution to the community. It can be downloaded at http://www.dillobits.com/icecast-2.3.1-patch.txt .
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/864Icecast 2.3.1 reports "too many sources connected" when it probably shouldn't.2018-03-06T12:49:49ZOscar SundbomIcecast 2.3.1 reports "too many sources connected" when it probably shouldn't.I have configured Icecast with <sources>8</sources> and six "special" streams, to set up a local fallback file to play for each, in case a source isn't currently connected.
The sources are connected in sets of three. When the first set ...I have configured Icecast with <sources>8</sources> and six "special" streams, to set up a local fallback file to play for each, in case a source isn't currently connected.
The sources are connected in sets of three. When the first set connects, all works fine. When the second set connects, (at least) the last client gets refused with
"too many sources connected". The sources all get connected before any of them start
sending data. I'm thinking Icecast might calculate that it already has six sources (three connected, three fallbacks) and adding three more adds up to nine, which is one more than allowed.
Raising <sources> to 16 fixed the problem, so there is an easy workaround, but to me it's counterintuitive that it should work that way.
This bug, in turn, sparks a bug in libshout, which killed the program providing the last tree streams (double free or corruption), but that's a whole other bug report.
Snippets from icecast.xml:
<limits>
<clients>200</clients>
<sources>8</sources>
<threadpool>6</threadpool>
<queue-size>524288</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>
---------
<mount>
<mount-name>/rocket_hi.ogg</mount-name>
<fallback-mount>/silence.ogg</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<mount>
<mount-name>/rocket_hi.mp3</mount-name>
<fallback-mount>/silence_hi.mp3</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<mount>
<mount-name>/rocket_lo.mp3</mount-name>
<fallback-mount>/silence_lo.mp3</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<mount>
<mount-name>/thsradio_hi.ogg</mount-name>
<fallback-mount>/silence.ogg</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<mount>
<mount-name>/thsradio_hi.mp3</mount-name>
<fallback-mount>/silence_hi.mp3</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<mount>
<mount-name>/thsradio_lo.mp3</mount-name>
<fallback-mount>/silence_lo.mp3</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/857On-demand streaming2018-03-06T12:49:49ZNowhere ManOn-demand streamingIt would be great if Icecast had an on-demand mode, where it starts the streaming of a file by it's start, maybe by starting the source program (e.g. ices or ezstream), or by grabbing the content by any other mean.It would be great if Icecast had an on-demand mode, where it starts the streaming of a file by it's start, maybe by starting the source program (e.g. ices or ezstream), or by grabbing the content by any other mean.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/842IceCast Server - Source Bytes in Access Log2018-03-06T12:49:49ZGitlab BotIceCast Server - Source Bytes in Access LogIn the access log of the IceCast server, can we have the number of bytes uploaded from a source, on disconnection? Currently only 19 bytes, the OK response when the source connectes, are shown here. The absence of this data means sources...In the access log of the IceCast server, can we have the number of bytes uploaded from a source, on disconnection? Currently only 19 bytes, the OK response when the source connectes, are shown here. The absence of this data means sources are able to upload many gigabytes of data without a clean and easy way of server admins tracking this (ie via scraping log files). Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/827Icecast server program crashes2018-03-06T12:49:49ZusamusicaIcecast server program crashesIcecast seems to stop running get message Icecast has encountered a error and must close.
Broadcast goes down. Running Windows server 2003
Not sure what information you will need to help you guys out?Icecast seems to stop running get message Icecast has encountered a error and must close.
Broadcast goes down. Running Windows server 2003
Not sure what information you will need to help you guys out?Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/810[PATCH] Announce ability for range requests2018-03-06T12:49:49Zmcbicecast[PATCH] Announce ability for range requestsThe file server now accepts a Range: header, so it would be best to announce this in the response headers. Two lines of code added to fserve.c, patch follows.
--- fserve.c.orig Thu Sep 8 16:03:51 2005
+++ fserve.c Wed Jan 4 ...The file server now accepts a Range: header, so it would be best to announce this in the response headers. Two lines of code added to fserve.c, patch follows.
--- fserve.c.orig Thu Sep 8 16:03:51 2005
+++ fserve.c Wed Jan 4 15:12:39 2006
@@ -514,6 +514,7 @@
bytes = snprintf (httpclient->refbuf->data, BUFSIZE,
"HTTP/1.1 206 Partial Content\r\n"
"Date: %s\r\n"
+ "Accept-Ranges: bytes\r\n"
"Content-Length: " FORMAT_INT64 "\r\n"
"Content-Range: bytes " FORMAT_INT64 \
"-" FORMAT_INT64 "/" FORMAT_INT64 "\r\n"
@@ -548,6 +549,7 @@
httpclient->respcode = 200;
bytes = snprintf (httpclient->refbuf->data, BUFSIZE,
"HTTP/1.0 200 OK\r\n"
+ "Accept-Ranges: bytes\r\n"
"Content-Length: " FORMAT_INT64 "\r\n"
"Content-Type: %s\r\n\r\n",
content_length,
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/803Max listeners causes server crash2018-03-06T12:49:49ZDavidMax listeners causes server crashI have a mount without a username, where username is blank <username></username>.
I set max listeners to 1 and connected to the source as a 2nd listener and it crashed the server.. First connection was from winamp 2nd connection was fro...I have a mount without a username, where username is blank <username></username>.
I set max listeners to 1 and connected to the source as a 2nd listener and it crashed the server.. First connection was from winamp 2nd connection was from WMP.
Will test the 2nd listener from a differnt computer. because most people will not launch 2 seprate connections from the same machine. stay tuned....Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/798Nothing appears on icecast when i'm broadcasting2018-03-06T12:49:49ZdeepbluesensationsNothing appears on icecast when i'm broadcastingHello there,
My server is saying that i'm broadcasting, but i find no traces of my program on icecast at my usual page, then nobody can listen to my program...
grrrr
The SmurfHello there,
My server is saying that i'm broadcasting, but i find no traces of my program on icecast at my usual page, then nobody can listen to my program...
grrrr
The SmurfMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/794[PATCH] Autotools and header fixes2018-06-15T21:35:52Zgtgbr[PATCH] Autotools and header fixes* Improve autotools handling of sys/time.h and time.h -- it should be checked whether both may be included simultaneously.
* Actually use the XIPH_C__FUNC__ macro, since #ifdef __SUNPRO_C was removed from src/compat.h
* A bit of header...* Improve autotools handling of sys/time.h and time.h -- it should be checked whether both may be included simultaneously.
* Actually use the XIPH_C__FUNC__ macro, since #ifdef __SUNPRO_C was removed from src/compat.h
* A bit of header/includes cleanup. Icecast sources search for support libs locally first, not in system include paths.
* Remove spurious CRs
* Do not let Windows include <stdio.h> twice in src/util.cMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/789Use proper function prototypes and declarations (2/2)2018-03-06T12:49:49ZgtgbrUse proper function prototypes and declarations (2/2)ANSI C requires function prototype and declaration to be of the same static'ness.ANSI C requires function prototype and declaration to be of the same static'ness.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/788Use proper function prototypes and declarations (1/2)2018-03-06T12:49:49ZgtgbrUse proper function prototypes and declarations (1/2)void foobar();
is not the same as
void foobar(void);
Fix those, and while around in auth.h, de-lint the enum.void foobar();
is not the same as
void foobar(void);
Fix those, and while around in auth.h, de-lint the enum.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/787[PATCH] Clean up remaining signedness issues2018-03-06T12:49:49Zgtgbr[PATCH] Clean up remaining signedness issuesRecent versions of gcc on Linux, e.g. gcc on Debian/sarge (or rather, Debian/testing) complains a lot, making warnings less useful for easily spotting problems. The bulk of the warnings is taken care of in the incompatible_pointer patche...Recent versions of gcc on Linux, e.g. gcc on Debian/sarge (or rather, Debian/testing) complains a lot, making warnings less useful for easily spotting problems. The bulk of the warnings is taken care of in the incompatible_pointer patches, this cleans up the rest. After this, Icecast is -Wall clean on Linux again.
While around in src/util.c, fix up some int->size_t's.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/786Fix bad __FUNCTION__ defines2018-03-06T12:49:49ZgtgbrFix bad __FUNCTION__ definesAlso take into account that strrchr() may be used in some cases (e.g. on Windows), so adjust the headers.
Remove the __SUNPRO_C case, as it is taken care of during configure time by xiph_compiler.m4.Also take into account that strrchr() may be used in some cases (e.g. on Windows), so adjust the headers.
Remove the __SUNPRO_C case, as it is taken care of during configure time by xiph_compiler.m4.Michael SmithMichael Smith