Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:49Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/766a list of the last n songs played should be accessible to visitors through st...2018-03-06T12:49:49Zicecast.aphexa list of the last n songs played should be accessible to visitors through status.xslIcecast 2.5.0Philipp SchafftPhilipp Schaffthttps://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/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/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/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/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/844Dynamical Reload of config.xml on Win322018-03-06T12:49:49ZchristianDynamical Reload of config.xml on Win32Hi,
it would be great if I could reload the Config.XML file after editing without stopping and starting the server, because I don't want to loose my listeners. Would this be possible?
What we change is to add some mount points and ADD...Hi,
it would be great if I could reload the Config.XML file after editing without stopping and starting the server, because I don't want to loose my listeners. Would this be possible?
What we change is to add some mount points and ADD some more listening ports and ADD some aliases.
Thanks
ChristianIcecast 2.5.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/780[PATCH] Make refbufs use size_t for sizes instead of unsigned long2018-03-06T12:49:49Zgtgbr[PATCH] Make refbufs use size_t for sizes instead of unsigned longThis may or may not solve any real issues on 64bit archs at the moment, but it surely is more correct and makes large parts of Icecast code more consistent, where adding casts would be necessary otherwise.
This is the first of a long se...This may or may not solve any real issues on 64bit archs at the moment, but it surely is more correct and makes large parts of Icecast code more consistent, where adding casts would be necessary otherwise.
This is the first of a long series of patches that are supposed to enhance Icecast's maintainability, portability and correctness. They are the result of an ongoing (and by now week-long) audit that shows that there are subtle issues hidden in Icecast that only work by accident at this point -- fixing those will make it much easier on the long run to maintain Icecast's quality.Karl HeyesKarl Heyeshttps://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/781Facilitate auditing by explicitly using "unsigned int" instead of just "unsig...2018-03-06T12:49:49ZgtgbrFacilitate auditing by explicitly using "unsigned int" instead of just "unsigned"Improves readability and makes code more consistent.Improves readability and makes code more consistent.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 Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/782Treat ICECAST_VERSION_STRING as user-settable ...2018-03-06T12:49:49ZgtgbrTreat ICECAST_VERSION_STRING as user-settable ...... and thus protect format strings from it. There's also this feature request that people want to be able to set the version string in the configuration file, so this patch prepares for that feature's implementation.... and thus protect format strings from it. There's also this feature request that people want to be able to set the version string in the configuration file, so this patch prepares for that feature's implementation.Michael SmithMichael Smithhttps://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/881dump-file limits to 2gb2018-03-06T12:49:49Ztutdump-file limits to 2gbWith such config stream.mp3 grows to 2147483647 bytes (2GB-1byte) and stops. Server proceed without problems.
```
<mount>
<mount-name>/stream</mount-name>
<dump-file>/home/user/dump/stream.mp3</dump-file>
</mo...With such config stream.mp3 grows to 2147483647 bytes (2GB-1byte) and stops. Server proceed without problems.
```
<mount>
<mount-name>/stream</mount-name>
<dump-file>/home/user/dump/stream.mp3</dump-file>
</mount>
```
icecast 2.3.1
gentoo linux
pentium4Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/783[PATCH] Explicitly casts for (un)signed char* conversions (1/3)2018-03-06T12:49:49Zgtgbr[PATCH] Explicitly casts for (un)signed char* conversions (1/3)Pass 1/3: Add XMLSTR(str) macro to cast to (xmlChar *). Requires a fix to global.h, which needs to #include "avl/avl.h" for its avl_tree usage.Pass 1/3: Add XMLSTR(str) macro to cast to (xmlChar *). Requires a fix to global.h, which needs to #include "avl/avl.h" for its avl_tree usage.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/895error : xmlEncodeEntitiesReentrant : char out of range2018-03-06T12:49:49ZJ.Antonioerror : xmlEncodeEntitiesReentrant : char out of rangeI am receiving the following error: "error : xmlEncodeEntitiesReentrant : char out of range
It happens when a station is sending accents within the metatags.
For example: "La Estación de la Asociación Mexicana de Pediatría" appears as ...I am receiving the following error: "error : xmlEncodeEntitiesReentrant : char out of range
It happens when a station is sending accents within the metatags.
For example: "La Estación de la Asociación Mexicana de Pediatría" appears as "La Estaci??e la Asociaci??exicana de Pediatría".
Happens with any source client I have tried: Sam, Oddcast, etc.
It totally breaks the status.xsl ... for example, "Radio Pediatría" turns into "Radio Pediatr?/td>" (it eats away the < in front of the </td>) and this in turns breaks other applications which read the stats from status.xls... like Sam2.
We have experienced this issue because most of our stations use accents.Icecast 2.3Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/784[PATCH] Explicitly casts for (un)signed char* conversions (2/3)2018-03-06T12:49:49Zgtgbr[PATCH] Explicitly casts for (un)signed char* conversions (2/3)Pass 2/3: Add another macro, CCPSTR(str), for the other way round: casts to (const char *).Pass 2/3: Add another macro, CCPSTR(str), for the other way round: casts to (const char *).Michael 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/785[PATCH] Explicitly casts for (un)signed char* conversions (3/3)2018-03-06T12:49:49Zgtgbr[PATCH] Explicitly casts for (un)signed char* conversions (3/3)Mop up the rest ... after this, lint is happy about it (gcc on recent Linux dists isn't quite happy yet, though.)Mop up the rest ... after this, lint is happy about it (gcc on recent Linux dists isn't quite happy yet, though.)Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/913incorrect mime-type for AAC files on Windows2018-03-06T12:49:49Zharreldincorrect mime-type for AAC files on WindowsIcecast on Windows sends the wrong mime-type to a client for AAC-files.
It is sending "application/octet-stream" in stead of "audio/aac" or "audio/aacp".
this occurs only with files, live streams encoded by an AAC(+) encoder is being han...Icecast on Windows sends the wrong mime-type to a client for AAC-files.
It is sending "application/octet-stream" in stead of "audio/aac" or "audio/aacp".
this occurs only with files, live streams encoded by an AAC(+) encoder is being handled correctly.
The reason for this is probably that icecast searches for mime-types on the wrong place.
The result is that players that expect the audio/aac(p) mime-type for AAC-files, do not play AAC-files served by icecast.Icecast 2.3Michael SmithMichael Smith