Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:50:21Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/567Icecast2 W32 Forms Client -> Windows Service2018-03-06T12:50:21ZjasonrIcecast2 W32 Forms Client -> Windows Service```
I think it makes sense to run the Icecast2 server as a Windows Service in this
environment as opposed to my current workaround as having it run as an alway
logged-in underprivilaged account under terminal services on Windows Server...```
I think it makes sense to run the Icecast2 server as a Windows Service in this
environment as opposed to my current workaround as having it run as an alway
logged-in underprivilaged account under terminal services on Windows Server
2003.
Same goes for ezstream, of course. =)
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/590Credits does not work2018-03-06T12:50:21ZGitlab BotCredits does not workHello
http://downloads.us.xiph.org/releases/icecast/icecast2_win32_2.2.0RC1_setup.exe
About -> Credits
does not work for me
WinXP Pro SP2 German;
AMD XP 2000+Hello
http://downloads.us.xiph.org/releases/icecast/icecast2_win32_2.2.0RC1_setup.exe
About -> Credits
does not work for me
WinXP Pro SP2 German;
AMD XP 2000+Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/591Bandwidth stats2023-01-03T19:11:54ZGitlab BotBandwidth statsIn icecast1 it was possible to fetch the current used/maximum bandwidth on the server. It seems like these stats got lost in the icecast2 rewrite, and it would be neat to have them back.
It's not anything critical, but it's good to be ab...In icecast1 it was possible to fetch the current used/maximum bandwidth on the server. It seems like these stats got lost in the icecast2 rewrite, and it would be neat to have them back.
It's not anything critical, but it's good to be able to see how much bandwidth the server uses.Icecast 2.6Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/593Tracking mountpoint bandwidth usage (from mailing list)2023-01-03T10:28:03ZAaron PaulleyTracking mountpoint bandwidth usage (from mailing list)Karl asked me to submit this to trac.xiph.org, from the mailing list.
I exclusively use mountpoints to setup my clients' streams. What would be absolutely amazing is if Icecast could log bandwidth usage per mountpoint, so I can better s...Karl asked me to submit this to trac.xiph.org, from the mailing list.
I exclusively use mountpoints to setup my clients' streams. What would be absolutely amazing is if Icecast could log bandwidth usage per mountpoint, so I can better see which mountpoints are using more or less of the bandwidth. I'm using mrtg to monitor the whole server, but it, and every stats program I've tried, has no way of differentiating the various mountpoints.
Thanks!Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/595fallback management in /admin/ interface2018-06-15T21:35:14ZMike Altrionfallback management in /admin/ interfaceIt would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.It would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/597Missing auth.xsl file in Win32 version of icecast2.22018-03-06T12:50:21ZpemMissing auth.xsl file in Win32 version of icecast2.2The auth.xsl file seems to be missing in the Win32 install of icecast2.2
If such a feature could not be used in Win32, it could be nice to specify it in the doc.The auth.xsl file seems to be missing in the Win32 install of icecast2.2
If such a feature could not be used in Win32, it could be nice to specify it in the doc.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/599please detatch stdin, stdout and stderr from the terminal on backgrounding (-b)2018-03-06T12:50:21Zandreplease detatch stdin, stdout and stderr from the terminal on backgrounding (-b)not doing so will sometimes make the shell you used to start icecast with hang when you later want to exit it, and some xml-libs icecast uses often also suddenly spew errors right into the terminal.
a workaround I use sometimes is to st...not doing so will sometimes make the shell you used to start icecast with hang when you later want to exit it, and some xml-libs icecast uses often also suddenly spew errors right into the terminal.
a workaround I use sometimes is to start icecast with icecast2 -b -c blah 0>/dev/null 1>&0 2>&0 (bash redirections, and taken from memory, beware)Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/600Make listenurl and server_url links on stats.xsl2018-03-06T12:50:21ZJoel EbelMake listenurl and server_url links on stats.xslI think it would be very convenient if the stats.xsl created links for the values of listenurl and server_url, just like status.xsl does. It would be great to just be able to click on those values to listen to a particular stream.I think it would be very convenient if the stats.xsl created links for the values of listenurl and server_url, just like status.xsl does. It would be great to just be able to click on those values to listen to a particular stream.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/614AACPlus Problems...2018-03-06T12:50:21ZjbutiAACPlus Problems...OK - Icecast 2.2.0 does in fact stream AACPlus - however, when attempting to connect with a MAC and VLC - you get nothing - no audio and log shows GARBAGE IN. If I point the AACPlus stream to shoutcast and stream with that - everything ...OK - Icecast 2.2.0 does in fact stream AACPlus - however, when attempting to connect with a MAC and VLC - you get nothing - no audio and log shows GARBAGE IN. If I point the AACPlus stream to shoutcast and stream with that - everything is 100% ok and I get audio. Can someone tell me if I am doing something wrong or is there actually a bug in the server software (2.2.0)?
ThanksMichael SmithMichael Smithhttps://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/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/628basic http auth doesn't work for the icecast 2.2.0 webroot2018-03-06T12:50:21ZGitlab Botbasic http auth doesn't work for the icecast 2.2.0 webrootWhen using the fileserve feature of icecast (2.2.0 currently) there is currently no way to prevent unauthorized users from accessing the files in the webroot - which could be soundfiles you can't make accessible for the public because of...When using the fileserve feature of icecast (2.2.0 currently) there is currently no way to prevent unauthorized users from accessing the files in the webroot - which could be soundfiles you can't make accessible for the public because of copyright reasons.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/630pidfile and changeowner2018-03-06T12:50:21ZStephane Billiartpidfile and changeownerit would be nice to write the pidfile as root, i.e. before _ch_root_uid_setup in main.c
this would allow to save the pidfile in a system directory (/var/run) instead of a private
directory
most daemons who change their uid bahave like t...it would be nice to write the pidfile as root, i.e. before _ch_root_uid_setup in main.c
this would allow to save the pidfile in a system directory (/var/run) instead of a private
directory
most daemons who change their uid bahave like this (apache, squid, ntop, ...)Michael 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/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/633Client count in stats.xml continues to increase.2018-03-06T12:50:22ZJoel EbelClient count in stats.xml continues to increase.In stats.xml, the <icestats><clients> value continually increases. Every time I restart a source, this number goes up and never comes back down. Right now it's up to 432 even though I have a 100 client limit. It seems that when a sour...In stats.xml, the <icestats><clients> value continually increases. Every time I restart a source, this number goes up and never comes back down. Right now it's up to 432 even though I have a 100 client limit. It seems that when a source disconnects, this client value doesn't decrement, but when a listening client disconnects it does. There could be more to it than that, but that's what it appears to be to me.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/635icecast 2.2.0 bugz2018-11-10T12:58:03ZGitlab Boticecast 2.2.0 bugz1) The XSL parser has some unchecked buffers (local),but they dont seem
to be exploitable. If they are, they can be used for priviledge escalation,
under the user that the server runs.
```xslt
<xsl:when test="<lots of chars>"></xsl...1) The XSL parser has some unchecked buffers (local),but they dont seem
to be exploitable. If they are, they can be used for priviledge escalation,
under the user that the server runs.
```xslt
<xsl:when test="<lots of chars>"></xsl:when>
<xsl:if test="<lots of chars>"></xsl:if>
<xsl:value-of select="<lots of chars>" />
```
2) Cause XSL parser error "Could not parse XSLT file". (Not very useful).
```
GET /status.xsl> HTTP/1.0
GET /status.xsl< HTTP/1.0
GET /<status.xsl HTTP/1.0
```
3) XSL parser bypass. (Useful to steal customized XSL files, lol).
```
GET /auth.xsl. HTTP/1.0
GET /status.xsl. HTTP/1.0
```
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/640last character of playlist log is truncated2018-03-06T12:50:22Zbirbecklast character of playlist log is truncatedIn Icecast version 2.2.0 the last character of the playlist log is truncated.
In the function update_comments on line 252 of format_ogg.c the line is
len += strlen(artist) + strlen(title) + 3;
the line should read
len += strlen(art...In Icecast version 2.2.0 the last character of the playlist log is truncated.
In the function update_comments on line 252 of format_ogg.c the line is
len += strlen(artist) + strlen(title) + 3;
the line should read
len += strlen(artist) + strlen(title) + 4;
I have applied to patch to my source tree and the playlist log reads correctly.
Michael 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/652Move clients to fallback when source disconnects2018-03-06T12:50:21ZTristanMove clients to fallback when source disconnectsCurrently, when a source disconnects, icecast2 appears to drop that mount's listening clients -- even if it has a fallback-mount defined. It would be nice if the existing clients were gracefully moved to the fallback instead of being di...Currently, when a source disconnects, icecast2 appears to drop that mount's listening clients -- even if it has a fallback-mount defined. It would be nice if the existing clients were gracefully moved to the fallback instead of being disconnected.
I know there's a mechanism to move clients, but I don't have prior knowledge of when the source will disconnect (ezstream is prone to SIGSEGV).Michael SmithMichael Smith