Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:48Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1359[PATCH] <stream-name> config to completely override stream name2018-03-06T12:49:48Zrich_d_thomas[PATCH] <stream-name> config to completely override stream nameHi,
This enhancement request is as a result of discussion thread http://icecast.imux.net/viewtopic.php?t=5033
Please could the code be changed so that all aspects of the "stream name" is overwritten by the contents of the <stream-name>...Hi,
This enhancement request is as a result of discussion thread http://icecast.imux.net/viewtopic.php?t=5033
Please could the code be changed so that all aspects of the "stream name" is overwritten by the contents of the <stream-name> tag in the config.xml file.
Currently, <stream-name> sets what appears in the displayed status.xsl page. The stream name that appears in the listener's player is still what is set in the source client and not what is set in <stream-name>
Thank you.
rich_d_thomas@hotmail.com
Icecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1354pass stream_name and stream_description to on-dis/connect scripts2018-03-06T12:49:48Zrich_d_thomaspass stream_name and stream_description to on-dis/connect scriptsHi,
I notice that the name of the mount point is already passed as an argument to the <on-disconnect> and <on-connect> scripts.
Please could the stream_name and stream_description be passed as additional arguments to these scripts.
Th...Hi,
I notice that the name of the mount point is already passed as an argument to the <on-disconnect> and <on-connect> scripts.
Please could the stream_name and stream_description be passed as additional arguments to these scripts.
Thanks in advance.
rich_d_thomas@hotmail.comIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1323Incorrect build instructions in icecast README2018-03-06T12:49:48ZMonty MontgomeryIncorrect build instructions in icecast README...don't forget to update the Icecast README to reflect proper build instruction now that it's automake'd. It's confused a few users this week....don't forget to update the Icecast README to reflect proper build instruction now that it's automake'd. It's confused a few users this week.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1309Server does not move new listeners to fallback source if specified via HTTP r...2018-03-06T12:49:48ZleeServer does not move new listeners to fallback source if specified via HTTP requestIcecast server 2.3.1 in Debian Etch
Server does not move new listeners to fallback source if specified via HTTP request. I have two examples of this not functioning as expected:
1) Listeners are connected to a mountpoint named "/". "/"...Icecast server 2.3.1 in Debian Etch
Server does not move new listeners to fallback source if specified via HTTP request. I have two examples of this not functioning as expected:
1) Listeners are connected to a mountpoint named "/". "/" has no fallback defined in server XML. An HTTP request to define a fallback is issued, in my case it looks like this:
http://ash.rockingtiger.com:8000/admin/fallbacks?mount=/&fallback=/live-1.mp3
When source disconnects, current listeners are moved to "/live-1.mp3" as expected. When a new listener connects to "/" the client (in this case iTunes) is given a 404. My expectation was the new clients that connect to "/" be moved to "/live-1.mp3" the same way the old clients were moved.
2) Listeners are connected to "/". "/" has a fallback of "/live-2.mp3" defined. An HTTP request to define a fallback is issued, in my case it looks like this:
http://ash.rockingtiger.com:8000/admin/fallbacks?mount=/&fallback=/live-1.mp3
When source disconnects, current listeners are moved to "/live-1.mp3" as expected. New clients that connect to "/" are moved to "/live-2.mp3", not "/live-1.mp3" as expected.Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1296Freeze Metadata2018-11-08T14:02:57ZGitlab BotFreeze Metadatait will be cool if i can myself determine artist or title that will be seen in winamp while streaming it can be done for example
<mount>
<mount-name>/Mount</mount-name>
<password>password</password>
<artist-name>...it will be cool if i can myself determine artist or title that will be seen in winamp while streaming it can be done for example
<mount>
<mount-name>/Mount</mount-name>
<password>password</password>
<artist-name> Artist name </artist-name>
</mount>
and in winamp i will see "Artist name" (current song that is playing) it is very usefull when u don`t want listeners to see names of tracks and ur streaming program can`t off sending metadata for example virtual dj or tractor
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1273<relay> ignores <authentication> elements2018-03-06T12:49:48Zmuelli<relay> ignores <authentication> elementsIf you just relay streams and want users to authenticate in order to get the stream, I'd expect to extend my <relay> definition by a `<authentication type="">` stanza. However, this does not work.
A rather counter-intuitive solution is...If you just relay streams and want users to authenticate in order to get the stream, I'd expect to extend my <relay> definition by a `<authentication type="">` stanza. However, this does not work.
A rather counter-intuitive solution is to set up a `<mount>` with the same name and define authentication there.
I'd expect an `<authentication>` inside a `<relay>` to work.
Example configuration which I expected to work:
```
<relay>
<server>some.server.net</server>
<port>8000</port>
<mount>/remotemount</mount>
<local-mount>/relay-auth</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
<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="auth_header" value="icecast-auth-user: 1"/>
<option name="listener_remove" value="http://myauthserver.net/notify_listener.php"/>
</authentication>
</relay>
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1272Moving clients on authentication failure2020-10-18T16:15:17ZmuelliMoving clients on authentication failureI want to move a client if she didn't pass my url authentication.
e.g.
```
<mount>
<mount-name>/mount</mount-name>
<authentication type="url">
<option name="mount_add" value="http://some/url"/>
...I want to move a client if she didn't pass my url authentication.
e.g.
```
<mount>
<mount-name>/mount</mount-name>
<authentication type="url">
<option name="mount_add" value="http://some/url"/>
<option name="mount_remove" value="http://some/url"/>
<option name="listener_add" value="http://some/url"/>
<option name="listener_remove" value="http://some/url"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
<!-- 1st example. Moving to other mount -->
<on-authentication-failure>/othermount</on-authentication-failure>
<!-- 2nd example. Playing pre-recorded file -->
<on-authentication-failure>/sorry.ogg</on-authentication-failure>
<!-- 3rd example. Firstplaying pre-recorded file, then play the stream anyway (or move to other mount) -->
<on-authentication-failure>sorry.ogg+/othermount</on-authentication-failure>
</mount>
```
Especially the 3rd example looks difficult, but I'd say it's a legitimate use-case to tell the listener that she didn't authenticate properly and is now getting e.g. a lower quality stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1271missing comprehensive list of configuration directives2018-03-06T12:49:48Zmuellimissing comprehensive list of configuration directivesI just wanted to lookup the semantic of a configuration directive and couldn't find it easily. A comprehensive list like on http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives would be nice.I just wanted to lookup the semantic of a configuration directive and couldn't find it easily. A comprehensive list like on http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives would be nice.Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1233icecast loops listener count to full2018-03-06T12:49:48ZGitlab Boticecast loops listener count to fullThe broblem occurs when streaming theora video with ffmpeg2theora and ezstream. Ezstream connects to icecast, but ffmpeg2theora don't send headers.(?) Status page shows only mountpoint information, nothing other.
After this like stream...The broblem occurs when streaming theora video with ffmpeg2theora and ezstream. Ezstream connects to icecast, but ffmpeg2theora don't send headers.(?) Status page shows only mountpoint information, nothing other.
After this like stream goes up and someone opens stream (ie. relaying icecast) this bug is activating. Same listener is added to clients list untill server is full.
Error log is like this:
```
[2007-08-30 01:34:34] DBUG source/source_main Client added
[2007-08-30 01:34:34] DBUG source/source_main Client added
[2007-08-30 01:34:34] DBUG source/source_main Client added
[2007-08-30 01:34:34] DBUG source/source_main Client added
[2007-08-30 01:34:34] DBUG source/source_main Client added
[2007-08-30 01:34:34] DBUG source/source_main Client added
[2007-08-30 01:34:34] DBUG source/source_main Client added
```
.... and continues to max listeners count of server.
Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1220adding IP change feature for those who don't have static IP's.2018-03-06T12:49:48Ztigger76adding IP change feature for those who don't have static IP's.I have verizon DSL and only dynamic IP's. I can't get a static IP from Verizon. but to keep my listeners tuned into my IP/radio server can you implement a IP poll feature that will notify the icecast stream directory of a new IP when dyn...I have verizon DSL and only dynamic IP's. I can't get a static IP from Verizon. but to keep my listeners tuned into my IP/radio server can you implement a IP poll feature that will notify the icecast stream directory of a new IP when dynamic IP's change? so even though my server is still on, your software will tell the icecast stream directory that I have a new IP and my listeners can still connect when it does.
this will prevent me from having to constantly having to edit my hostname IP every time shutting down my service.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1195StreamTitle Template for Icecast 22018-11-08T14:02:03ZscratchStreamTitle Template for Icecast 2In Icecast 1 it seemed to be possible to append or prepend a string to a title using a StreamTitle template (this is also possible in shoutcast):
for example:
[yourRadioName] %s
became
[yourRadioName] Some Artist - Some Title
I am not ...In Icecast 1 it seemed to be possible to append or prepend a string to a title using a StreamTitle template (this is also possible in shoutcast):
for example:
[yourRadioName] %s
became
[yourRadioName] Some Artist - Some Title
I am not a coder, and i think icecast2 is Great (good work),
but since it was possible before, I think it shouldn't be so hard
to be able to modify that metadata before icecast sends it to the listeners.
I know you can set such options in a source client, but as you have many djs or channels with their own setups, it provides a standard in the title format. Also, when you would want to set up a commercial service, all stations could be marked with your "powered by".Icecast 2.5.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1132was shout_perl-2.0.2 lost?2018-03-06T12:49:48ZGitlab Botwas shout_perl-2.0.2 lost?I have in my possession Shout.pm with version 2.0.2 but in the svn.xiph.org repository I can only see up to 2.0.1. Was 2.0.2 lost during the transition from cvs?
After many years I'm setting up a new Icecast2 server and I need this comp...I have in my possession Shout.pm with version 2.0.2 but in the svn.xiph.org repository I can only see up to 2.0.1. Was 2.0.2 lost during the transition from cvs?
After many years I'm setting up a new Icecast2 server and I need this component. I could copy from the old server but it would better if you had it :-)
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1115Icecast+IE7+flash mp3 stream play2018-03-06T12:49:48ZbenpetiIcecast+IE7+flash mp3 stream playI'm not sure if it is true, maybe Icecast is already patched against it.
I read that I have to patch Icecast if I want to play the stream in flash, in IE7.
You can find the detailed description here:
www.jeroenwijering.com/?thread=Stream...I'm not sure if it is true, maybe Icecast is already patched against it.
I read that I have to patch Icecast if I want to play the stream in flash, in IE7.
You can find the detailed description here:
www.jeroenwijering.com/?thread=Streaming_IceCastMichael SmithMichael Smithhttps://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/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/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 Smith