Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:48Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1896Icecast should provide xml versions of pages2018-03-06T12:49:48ZGhost UserIcecast should provide xml versions of pagesIcecast generates xml pages and then runs them through xslt to convert them to html for display. The raw xml is much more useful for people writing automation which accesses an icecast server.
While some of the raw xml files are availab...Icecast generates xml pages and then runs them through xslt to convert them to html for display. The raw xml is much more useful for people writing automation which accesses an icecast server.
While some of the raw xml files are available through the admin/ interface, this requires authentication. The same information that's available on the public stream listing and version pages should also be available as xml.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1892Allow transient reconfiguration of all mount point parameters2018-03-06T12:49:39ZThomas B. RückerAllow transient reconfiguration of all mount point parametersgive the source user more freedom in controlling mount point options through admin requests.
How do we split control of <mount> options?
We could have XML tag attributes to control outside access: <stream-name allow-override="no">fooba...give the source user more freedom in controlling mount point options through admin requests.
How do we split control of <mount> options?
We could have XML tag attributes to control outside access: <stream-name allow-override="no">foobar</stream-name>
where override could be:
* yes - allow setting this value externally
* no - only the xml config file value may set this
* 'unset' - a default value is used if the attribute is not set. The default should be documented though!
Also, we should check the life-cycle for this. Do the settings get reset to the XML defined settings and defaults upon disconnection of the source client or do they persist until either the config is reloaded or the server restarted? I'd tend towards the latter and give an option to 'reset' from source side both during connect and at arbitrary points in time.Icecast 2.6Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1889Error pages needs update2018-03-06T12:49:48ZPhilipp SchafftError pages needs updateThe error pages generated by icecast are currently hardcoded. Some contain invalid HTML.
Please provide a valid but very simple HTML file for the HTTP errors 400 and 404. I will also take such error pages for 401 and 403 but that has le...The error pages generated by icecast are currently hardcoded. Some contain invalid HTML.
Please provide a valid but very simple HTML file for the HTTP errors 400 and 404. I will also take such error pages for 401 and 403 but that has less priority.
The pages (except for 401) all take an string telling the user about the error. Please just leave '%s' in the 'template' where it should go.
current pages look like this:
```
<b>%s</b>
```Icecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1888Lower required authentification level for STATS2018-03-06T12:49:48ZcatoLower required authentification level for STATSThe STATS interface currently needs admin previleges. If you want to give an external entity access to the STATS interface you have to give them your admin password and therefore the control over the whole server. Requiring just e.g. rel...The STATS interface currently needs admin previleges. If you want to give an external entity access to the STATS interface you have to give them your admin password and therefore the control over the whole server. Requiring just e.g. relay previleges for the STATS interface would solve this.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1886[PATCH]Icecast should log to STDERR if it can't log to the errorlog file2018-03-06T12:49:48ZThomas B. Rücker[PATCH]Icecast should log to STDERR if it can't log to the errorlog fileThis would be very helpful for troubleshooting startup problems.
Likely to be implemented in log_write() or _log_open() in log/log.c.This would be very helpful for troubleshooting startup problems.
Likely to be implemented in log_write() or _log_open() in log/log.c.Icecast 2.5.0https://gitlab.xiph.org/xiph/icecast-server/-/issues/1885Icecast should allow manual HTTP header configuration2018-03-06T12:49:48ZThomas B. RückerIcecast should allow manual HTTP header configurationOne use case is: "Cross-origin resource sharing" which mandates
"Access-Control-Allow-Origin: http://example.com:8080"
Allowing CORS would simplify inclusion of custom XSLT (e.g. metadata) into other webservices.One use case is: "Cross-origin resource sharing" which mandates
"Access-Control-Allow-Origin: http://example.com:8080"
Allowing CORS would simplify inclusion of custom XSLT (e.g. metadata) into other webservices.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1880Join video streams on keyframes2018-03-06T12:49:39ZGregory MaxwellJoin video streams on keyframesFor keyframe based video (as opposed to rolling intra refresh) clients can't display output (correctly at least) until they hit a keyframe.
So it would be useful if streams started on keyframes. There are a couple options for this.
If ...For keyframe based video (as opposed to rolling intra refresh) clients can't display output (correctly at least) until they hit a keyframe.
So it would be useful if streams started on keyframes. There are a couple options for this.
If latency is unimportant and the server doesn't mind the memory usage it could buffer the span between keyframes and when a client attaches attach them back at the last keyframe. This would be like a keyframe adaptive preburst.
Alternatively, if latency matters more the server could reencode.
The best way to do this would be to constantly reencode with a very short keyframe interval (e.g. 1-12 frames) and play this out to new clients until a real keyframe comes. Optionally a 'loading' spinner could be displayed to avoid confusion from the low quality during this span. This is O(N) in the number of streams and O(1) in the number of users.
For some formats it would be possible to do some format specific smartness. E.g. in theora You could retransmit the prior keyframe timestamped as NOW-2, then reencode the prior frame (using all intra blocks at high quality) as NOW-1. Then splice in the stream. There will be some corruption until the next keyframe but it should be very minor. Unfortunately it would cause a jump in the visible output because the first frame is an old one.
Alternatively, alternatively, a pre-encoded short GOP "loading" video stream could be sent to users before the first new keyframe. Audio could be spliced in instantly however. This would avoid encoding in the icecast server.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1879Sources should be able to specify the latency they want2018-03-06T12:49:48ZGregory MaxwellSources should be able to specify the latency they wantIcecast has a lot of options to trade off latency vs smoothness, e.g. pre-burst, and will probably have more in the future.
It is _really_ _really_ annoying to have an interactive live stream, e.g. where people are responding in realtim...Icecast has a lot of options to trade off latency vs smoothness, e.g. pre-burst, and will probably have more in the future.
It is _really_ _really_ annoying to have an interactive live stream, e.g. where people are responding in realtime over IRC or other streams where the pre-burst is adding 5 seconds of delay. And it's a pain to go get access to the icecast server in order to turn off these features, as the server operator may not be easily available.
The stream source knows best if low latency is required. To the extent that the high latency features impact server scaling it may be useful if the server can still limit them, but absent forcing on the server the source should have a way to select.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1878[PATCH] This patch adds the possibility to put full urls in the list of strea...2019-01-03T16:34:53ZPhilipp Schafft[PATCH] This patch adds the possibility to put full urls in the list of streams fetched from the master server.(reposted from IRC, cato in #icecast)
This patch adds the possibility to put full urls in the list of streams fetched from the master server. When pointing the <master-relay-*> options to a script instead of an icecast this allows to se...(reposted from IRC, cato in #icecast)
This patch adds the possibility to put full urls in the list of streams fetched from the master server. When pointing the <master-relay-*> options to a script instead of an icecast this allows to setup relays of arbitrary streams easily.Icecast 2.4.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1877Binding to IPv6 broken on win32 Icecast?2020-02-14T13:01:05ZThomas B. RückerBinding to IPv6 broken on win32 Icecast?This was reported first by mharris on IRC.
He's running WinXP SP3.
I then tried to reproduce it on Win7 64bit with both Icecast 2.3.2 and Icecast 2.3.2-kh33.
On the official build icecast2console.exe will fail to start when given an IPv6...This was reported first by mharris on IRC.
He's running WinXP SP3.
I then tried to reproduce it on Win7 64bit with both Icecast 2.3.2 and Icecast 2.3.2-kh33.
On the official build icecast2console.exe will fail to start when given an IPv6 bind-address (both :: and [::] and also explicit address in both forms). On the KH build it starts but doesn't bind to a port.
I didn't manage to get useful logs out on the official build.
The KH build though complains in the form:
EROR connection/connection_setup_sockets Could not create listener socket on port 8000 bind ::
PS: Unless there is an instant fix, this will miss the window for 2.3.3.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1873[PATCH] icecast does not read arbitrary capitalized headers2018-03-06T12:49:48ZPhilipp Schafft[PATCH] icecast does not read arbitrary capitalized headers(Forwarded from cato on IRC because of #1871)
the YP-Interface does not work according to the http rfc. To be specific icecast does not read arbitrary capitalized headers from the answer as the standard says.
I have written my own impl...(Forwarded from cato on IRC because of #1871)
the YP-Interface does not work according to the http rfc. To be specific icecast does not read arbitrary capitalized headers from the answer as the standard says.
I have written my own implementation of the server-side yp-interface. when I return for example "Ypmessage: 1" instead of "YPMessage: 1" icecast doesn't find the header and the submission to my directory fails
Section 4.2 of RFC 2616 says: "Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
the error is in http://svn.xiph.org/icecast/trunk/icecast/src/yp.c in handle_returned_header(..) where instead of strncmp a case-insensitive comparison should be madeIcecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1870icecast should send 'expires' in all cases2018-03-06T12:49:48ZThomas B. Rückericecast should send 'expires' in all casescurrently it only sends it in a flash special case.
We should probably do this in all cases unless someone thinks it would break existing clients?currently it only sends it in a flash special case.
We should probably do this in all cases unless someone thinks it would break existing clients?Icecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1867Icecast shared sources in 'httpp', 'net', 'thread' and 'timing' directories n...2018-03-06T12:49:48ZThomas B. RückerIcecast shared sources in 'httpp', 'net', 'thread' and 'timing' directories need license header update (to LGPLv2)As just noticed on #icecast, among others the timing.c and httpp.c files seem to imply GPLv2 while COPYING in that directory says LGPLv2.
Those are also used by e.g. libshout which is LGPLv2...
Suggestion: track down authors, double che...As just noticed on #icecast, among others the timing.c and httpp.c files seem to imply GPLv2 while COPYING in that directory says LGPLv2.
Those are also used by e.g. libshout which is LGPLv2...
Suggestion: track down authors, double check that changing to LGPL is OK.
This would make them compatible with both GPLv2 and LGPLv2 if I understand correctly.
affected files relative to [icecast/trunk/](../tree/master/icecast/trunk/) and who touched them (since tagging GPL):
* [icecast/trunk/timing/timing.c](../tree/master/icecast/trunk/timing/timing.c) giles, karl
* [icecast/trunk/timing/timing.h](../tree/master/icecast/trunk/timing/timing.h) giles, karl, moritz
* [icecast/trunk/net/sock.h](../tree/master/icecast/trunk/net/sock.h) (oddly not sock.c) karl, oddsock, giles, brendan, msmith, jack. plus changes predating https://trac.xiph.org/browser/trunk/net/sock.h?rev=1997
* [icecast/trunk/httpp/httpp.c](../tree/master/icecast/trunk/httpp/httpp.c) msmith, giles, oddsock, karl, ph3-der-loewe
* [icecast/trunk/httpp/httpp.h](../tree/master/icecast/trunk/httpp/httpp.h) msmith, giles, karl, ph3-der-loeweThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1865Init script for icecast2018-03-06T12:49:48ZClaudius ZingerliInit script for icecastHi,
In order to automatically start icecast at system boot, I created a
startup script for icecast (adapted from /etc/init.d/openssh).
In order to make this work, you need to create:
cat /etc/sysconfig/icecast
#Icecast service startu...Hi,
In order to automatically start icecast at system boot, I created a
startup script for icecast (adapted from /etc/init.d/openssh).
In order to make this work, you need to create:
cat /etc/sysconfig/icecast
#Icecast service startup parameters
OPTIONS='-c /usr/local/etc/icecast.xml'
Adapt you icecast.xml to create a pid file in the standard location:
Instead of <pidfile>/usr/local/share/icecast/icecast.pid</pidfile> use:
<pidfile>/var/run/icecast.pid</pidfile>
(or adapt the init script to look in /usr/local)
Then put the following code in /etc/init.d/icecast and mark it
executable and do "chkconfig --add icecast" to register the service.
#!/bin/bash
#
# chkconfig: 2345 88 55
# Description: Icecast init.d script
# Adapted by zeuz from: openssh initd script
# Get function from functions library
. /etc/init.d/functions
# pull in sysconfig settings
[ -f /etc/sysconfig/icecast ] && . /etc/sysconfig/icecast
prog="icecast"
PID_FILE=/var/run/${prog}.pid
PROG_FILE=/usr/local/bin/${prog}
OPTIONS+=' -b'
RETVAL=0
# Start Icecast
start() {
echo -n $"Starting ${prog}: "
# echo -n $"${PROG_FILE} ${OPTIONS} >/dev/null 2>&1 && success ||
failure"
${PROG_FILE} ${OPTIONS} >/dev/null 2>&1 && success || failure
RETVAL=$?
[ "${RETVAL}" = 0 ] && touch /var/lock/subsys/${prog}
echo
}
# Stop Icecast
stop() {
echo -n $"Stopping ${prog}: "
if [ -n "`pidfileofproc ${prog}`" ] ; then
echo "killproc ${prog}"
else
failure $"Stopping ${prog}"
fi
RETVAL=$?
# if we are in halt or reboot runlevel kill all running sessions
# so the TCP connections are closed cleanly
if [ "x${runlevel}" = x0 -o "x${runlevel}" = x6 ] ; then
killall ${prog} 2>/dev/null
fi
[ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/${prog}
echo
}
### main logic ###
case "${1}" in
start)
start
;;
stop)
stop
;;
status)
status -p $PID_FILE ${prog}
RETVAL=$?
;;
condrestart)
if [ -f /var/lock/subsys/${prog} ] ; then
stop
sleep 3
start
fi
;;
restart|reload)
stop
start
;;
*)
echo $"Usage: $0 {start|stop|restart|reload|condrestart|status}"
RETVAL=1
esac
exit 0
I hope that helps. I think it might be useful. The code has been tested
on RHEL 5. Maybe someone could put that file in a contrib directory. (or
adapt the Makefile to automatically place the init script)
Cheers
ClaudiusMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1860[PATCH] Send credentials when doing master-relay2018-11-10T13:05:22Zcato[PATCH] Send credentials when doing master-relayWhen using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentia...When using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentials to the master-icecast. The natural choice would be to send the `<master-username>` and `<master-password>`.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1854GeoIP support for Icecast22018-03-06T12:49:48ZEugene MechanisMGeoIP support for Icecast2Everyone knows that a lot of stations using php and other scripts around icecast2 to get listeners stats, and also these scripts doing hard work on getting country flag and country and city and sometimes map coordinates for each listener...Everyone knows that a lot of stations using php and other scripts around icecast2 to get listeners stats, and also these scripts doing hard work on getting country flag and country and city and sometimes map coordinates for each listeners IP.
It's so terrible and not good for cpu usage etc.
Will be much better if icecast2 will do it. can be easily added support of geoip info so icecast2 will generate listeners stats with geoip details. and it's much less cpu/ram usage at all.
Can be used free GeoLite Country and GeoLite City databases. and C API look here http://www.maxmind.com/app/c
Foe example apache, nginx and others http servers offers geoIP modules. it's so painfull to write scripts around icecast2 just to get country flag and maybe some other info like city, country, map location etc. Icacast2 can do it easily and keep these stats in logs, in xml output etc.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1853Update graphics for Icecast documentation2018-03-06T12:49:39ZThomas B. RückerUpdate graphics for Icecast documentationRedoing some screenshots and graphics in a lossless format like PNG is desireable. Currently some are JPEG.
Please check back with dm8tbr as to when the web layout is final.
Target 2.3.3 if possible.Redoing some screenshots and graphics in a lossless format like PNG is desireable. Currently some are JPEG.
Please check back with dm8tbr as to when the web layout is final.
Target 2.3.3 if possible.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1851Should Icecast use $hostname instead of the value from the GET request for re...2018-11-10T12:44:08ZThomas B. RückerShould Icecast use $hostname instead of the value from the GET request for replies?Icecast uses the hostname supplied by the client in HTTP headers for replies. Should it use the hostname set in the config instead?
Target is 2.4.0
_after some discussion on IRC:_
It is apparent that the current behaviour is well suit...Icecast uses the hostname supplied by the client in HTTP headers for replies. Should it use the hostname set in the config instead?
Target is 2.4.0
_after some discussion on IRC:_
It is apparent that the current behaviour is well suited as general purpose default. (This e.g. prevents breaking in LAN/NAT/Internet setups or when the server is being accessed on different IPs and or different host names)
I am still of the opinion that there are several cases where being able to *optionally* override the hostname used in dynamic replies by the one set in the config does make sense.
* reverse proxies (although not recommended) might access the icecast server by only internally resolving host-names. This would deliver the client a broken generated playlist file.
* some server admins want to force a _single_ and _specific_ host name to be returned by the server (e.g. to ensure RRDNS, to avoid unauthorized 3rd parties defining FQDN for the server and having the server _return_ that unauthorized FQDN in dynamic playlists)
* http vs. https scenarios might break things too (e.g. different server/proxy/request-routing per port). _listenurl_ is *always* httpThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1846Icecast uses default source-password if it's not defined in config2018-03-06T12:49:48ZThomas B. RückerIcecast uses default source-password if it's not defined in configThis can be a security problem if <source-password> is not defined in the Icecast config file.
Under such conditions a *default* password will take effect.
Impact should be limited, as default config contains that tag, but there are co...This can be a security problem if <source-password> is not defined in the Icecast config file.
Under such conditions a *default* password will take effect.
Impact should be limited, as default config contains that tag, but there are constellations where e.g. an Icecast admin would unwittingly allow anyone to stream through their server.
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1843WebM support in Icecast2018-03-06T12:49:48ZBasil Mohamed GoharWebM support in IcecastAdd support for streaming WebM files in IcecastAdd support for streaming WebM files in IcecastMichael SmithMichael Smith