Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2021-10-30T09:42:21Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2061Investigate: Relay not recovering2021-10-30T09:42:21ZMarvin ScholzInvestigate: Relay not recoveringAs reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source...As reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source mountpoint is back.
> I had a problem where one of my relays has stopped relaying, and I couldn't bring it back up without a restart. It's only playing the fallback. It reloads the relay data from the master server, but ignores it somehow. It honors me changing the refresh interval in the config file and everything.
> The event seems to happen at 2014-10-12 05:41:13, and it never recovers or mentions the stream again
> If it helps, I don't see another "checking master stream list" for another 15 minutes: [2014-10-12 06:09:20] DBUG slave/_slave_thread checking master stream list
> Before 05:41, it occurs reliably every 120 secondsThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2412Icescc process get down and do not restart itself sometimes2021-10-31T11:32:47ZcyberIcescc process get down and do not restart itself sometimes[strace.txt](/uploads/0b296196b41a9b62159085c24fd67e08/strace.txt)
[error.log.txt](/uploads/809f04a4b7eeef67d881d18ecf70d3e3/error.log.txt)
Hi,
This is the version we currently have:
icecast-2.4.2
I have launched a strace to the proces...[strace.txt](/uploads/0b296196b41a9b62159085c24fd67e08/strace.txt)
[error.log.txt](/uploads/809f04a4b7eeef67d881d18ecf70d3e3/error.log.txt)
Hi,
This is the version we currently have:
icecast-2.4.2
I have launched a strace to the process, I have attached the result to you.
Application process icescc for puntoblancobase is down and should be up; restarting: successful
And in error.log for the station we see this:
```
<04/26/21@17:42:56> [source] source dropped connection. disconnecting.
<04/26/21@17:43:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:44:27> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:44:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:27> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:59> [source] connected from 127.0.0.1
<04/26/21@17:45:59> [source] icy-name:XXXXXXXX ; icy-genre:Unspecified
<04/26/21@17:45:59> [source] icy-pub:0 ; icy-br:64 ; icy-url:http://www.xxxxxxxxxxx.es
<04/26/21@17:45:59> [source] icy-irc: ; icy-icq: ; icy-aim:
```
But in other stations icescc do not restart till we do from panel:
```
<04/26/21@15:00:36> [source] source dropped connection. disconnecting.
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
```
.......
```
<04/26/21@16:22:16> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:16> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:24> [main] SIGTERM; exiting!
<04/26/21@16:22:29> [SHOUTcast] DNAS/Linux v1.9.8 (Feb 28 2007) starting up...
<04/26/21@16:22:29> [main] pid: 9099
<04/26/21@16:22:29> [main] loaded config from etc/server.conf
<04/26/21@16:22:29> [main] initializing (usermax:100 portbase:9122)...
<04/26/21@16:22:29> [main] No ban file found (etc/sc_serv.ban)
<04/26/21@16:22:29> [main] No rip file found (etc/sc_serv.rip)
<04/26/21@16:22:29> [main] opening source socket
<04/26/21@16:22:29> [main] source thread starting
<04/26/21@16:22:29> [main] opening client socket
<04/26/21@16:22:29> [main] Client Stream thread [0] starting
<04/26/21@16:22:29> [main] client main thread starting
<04/26/21@16:22:29> [source] listening for connection on port 9123
<04/26/21@16:22:33> [source] connected from 127.0.0.1
<04/26/21@16:22:33> [source] icy-name:XXXXXXXX ; icy-genre:Unspecified
<04/26/21@16:22:33> [source] icy-pub:0 ; icy-br:64 ; icy-url:http://www.xxxxxxxxx.es
<04/26/21@16:22:33> [source] icy-irc: ; icy-icq: ; icy-aim:
```
Could you tell us which could be the cause for this problem? And how to solve it?
Product name:
Centova Cast v3https://gitlab.xiph.org/xiph/icecast-server/-/issues/2420Cannot connect to icecast-radio on external sources (winamp), browser-based c...2021-10-31T13:29:41Zsuper sleepyCannot connect to icecast-radio on external sources (winamp), browser-based connection works fineI'm at my wits' end, here. I've tried listening from a different proxy, assuming that there's something wrong with my connection - anyway.
The source audio is [here](https://play.squid-radio.net/clouds). I get an access denied notifica...I'm at my wits' end, here. I've tried listening from a different proxy, assuming that there's something wrong with my connection - anyway.
The source audio is [here](https://play.squid-radio.net/clouds). I get an access denied notification - at best! - from winamp, or at worst it just rapidly tries to connect and fails without displaying any messages. Listening through the browser is a pretty strain on my memory, I want to see if this is an icecast issue, or if there's *any* ideas you might on what could be causing this. Any advice, and I do mean any advice, would be appreciated!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2422Programmatically set the fallback-override value2021-10-31T22:11:44Zisaac-codeProgrammatically set the fallback-override valueAs advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fall...As advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fallback, but immediately the mountpoint is back, I cannot programmatically switch back to the mountpoint
Switching back to the former mountpoint is only possible when the fallback-override value is set to 1, but I cannot achieve that because there is no way to programmatically achieve that, which is weird.
P.S. I want users to create mountpoints via an exposed endpoint, so I don't create it manually inside the icecase.xml filehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2134Please add SSL support for Master -> Slave relay connections2021-11-10T08:58:41ZJordan EricksonPlease add SSL support for Master -> Slave relay connectionsIn considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.In considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2423Allow setting the charset globally, not only on per-mount basis2021-11-15T18:41:48ZVadim UshakovAllow setting the charset globally, not only on per-mount basisHi! In my setup, I use a script that manages the sources dynamically, creating, starting and stopping mount points by user request. The icecast config is static, and all the sources share the same login/password. So no need to declare mo...Hi! In my setup, I use a script that manages the sources dynamically, creating, starting and stopping mount points by user request. The icecast config is static, and all the sources share the same login/password. So no need to declare mount points in icecast.xml in that case.
Unfortunately, IceCast uses the charset ISO8859-1 by default, and the only way to override it is declare mount point for each single source and specify `<charset>UTF-8</charset>` for each. This is extremely inconvenient.
I tried the following simple patch and seems to work. It allows to set the charset at the upper level so it takes effect for every mount point that doesn't explicitly override the value. If no charset is set at all, the default ISO8859-1 is used as the last resort.
Could you please merge it?
[global-charset.diff](/uploads/a1b7d890b0ea73d1d12fdf19b7b58209/global-charset.diff)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2424WARN connection/get_ssl_certificate Invalid cert file /home/icecast/icecast.c...2021-12-03T20:32:49ZAlex SirroshWARN connection/get_ssl_certificate Invalid cert file /home/icecast/icecast.certkeyVersion: icecast-2.4.4-2.1.x86_64 (opensuse)
Cert issuer: LetsEncrypt
File icecast.certkey is world-readable and contains concatenated fullchain.pem and a private key.
P.S.: Found a somewhat related issue on [github](https://github.com...Version: icecast-2.4.4-2.1.x86_64 (opensuse)
Cert issuer: LetsEncrypt
File icecast.certkey is world-readable and contains concatenated fullchain.pem and a private key.
P.S.: Found a somewhat related issue on [github](https://github.com/AzuraCast/AzuraCast/issues/2692)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2425Don't hardcode the pkg-config architecture, allowing crossbuilds2021-12-17T23:25:49ZUnit 193Don't hardcode the pkg-config architecture, allowing crossbuildsHowdy,
In Debian, there's a concerted effort to ensure crossbuilding works, the person that puts in the most effort on that submitted this patch:
```
Author: Helmut Grohne <helmutg@debian.org>
Description: FTCBFS: m4/shout.m4 hard code...Howdy,
In Debian, there's a concerted effort to ensure crossbuilding works, the person that puts in the most effort on that submitted this patch:
```
Author: Helmut Grohne <helmutg@debian.org>
Description: FTCBFS: m4/shout.m4 hard codes the build architecture pkg-config
ices2 fails to cross build from source, because it uses the build
architecture pkg-config. The cause is a bad macro in m4/shout.m4. After
fixing it, ices2 cross builds successfully. Please consider applying the
attached patch.
.
Note: I had to remove the setting of PKG_CONFIG_PATH, because Debian's
cross wrapper does not work when PKG_CONFIG_PATH is set. Anyway,
/usr/local/lib/pkgconfig is part of the default search path of
pkg-config, so that should not be a problem.
--- ices2-2.0.2.orig/m4/shout.m4
+++ ices2-2.0.2/m4/shout.m4
@@ -19,22 +19,18 @@
# NB: PKG_CHECK_MODULES exits if pkg-config is unavailable on the target
# system, so we can't use it.
-# seed pkg-config with the default libshout location
-PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-/usr/local/lib/pkgconfig}
-export PKG_CONFIG_PATH
-
# Step 1: Use pkg-config if available
-AC_PATH_PROG([PKGCONFIG], [pkg-config], [no])
-if test "$PKGCONFIG" != "no" && `$PKGCONFIG --exists shout`
+PKG_PROG_PKG_CONFIG
+if test "x$PKG_CONFIG" != x && `$PKG_CONFIG --exists shout`
then
- SHOUT_CFLAGS=`$PKGCONFIG --variable=cflags_only shout`
- SHOUT_CPPFLAGS=`$PKGCONFIG --variable=cppflags shout`
- SHOUT_LIBS=`$PKGCONFIG --libs shout`
+ SHOUT_CFLAGS=`$PKG_CONFIG --variable=cflags_only shout`
+ SHOUT_CPPFLAGS=`$PKG_CONFIG --variable=cppflags shout`
+ SHOUT_LIBS=`$PKG_CONFIG --libs shout`
xt_have_shout="maybe"
else
- if test "$PKGCONFIG" != "no"
+ if test "x$PKG_CONFIG" != x
then
- AC_MSG_NOTICE([$PKGCONFIG couldn't find libshout. Try adjusting PKG_CONFIG_PATH.])
+ AC_MSG_NOTICE([$PKG_CONFIG couldn't find libshout. Try adjusting PKG_CONFIG_PATH.])
fi
# pkg-config unavailable, try shout-config
AC_PATH_PROG([SHOUTCONFIG], [shout-config], [no])
```
This technically applies to the m4 module, which is to have issues filed in icecast-server.
Thanks!Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2417After working days without problem Icecast 2.4.4 not trying to update relays ...2022-02-19T09:59:17ZdanielsoheilAfter working days without problem Icecast 2.4.4 not trying to update relays from master serverthis my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<...this my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>600</header-timeout>
<source-timeout>600</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>196608</burst-size>
</limits>
<authentication>
<source-password>removed</source-password>
<relay-password>removed</relay-password>
<admin-user>admin</admin-user>
<admin-password>removed</admin-password>
</authentication>
<hostname>radio.myts3.ir</hostname>
<listen-socket>
<port>18000</port>
</listen-socket>
<http-headers>
<header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<master-server>192.168.100.53</master-server>
<master-server-port>8000</master-server-port>
<master-update-interval>30</master-update-interval>
<master-password>removed</master-password>
<relays-on-demand>0</relays-on-demand>
<fileserve>1</fileserve>
<paths>
<basedir>/usr/share/icecast</basedir>
<logdir>/var/log/icecast</logdir>
<webroot>/usr/share/icecast/web</webroot>
<adminroot>/usr/share/icecast/admin</adminroot>
<alias source="/" destination="/status-json.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel>
<logsize>100000</logsize>
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>
```
i have logs too, its 66mB i can't send it here.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2401Allow `icy-metadata` and `icy-metaint` in default CORS configuration2022-02-26T18:35:51ZEthan HalsallAllow `icy-metadata` and `icy-metaint` in default CORS configurationI noticed that many of the public streams I've encountered have a wide-open Access-Control-Allow-Origin policy, but do not allow access to request the `Icy-Metadata` header nor allow access to read the `Icy-MetaInt` header in the respons...I noticed that many of the public streams I've encountered have a wide-open Access-Control-Allow-Origin policy, but do not allow access to request the `Icy-Metadata` header nor allow access to read the `Icy-MetaInt` header in the response. This prevents any clients that honor CORS (i.e. browsers) from requesting or reading icy metadata.
This patch is to allow cross-origin access to the `Icy-MetaData` and `Icy-MetaInt` headers by default. Also, this patch inserts the `Access-Control-Allow-Headers` and `Access-Control-Expose-Headers` into the default XML configuration so that icy metadata works by default. Users can opt-out of it like they can with `Access-Control-Allow-Origin: *`.
The main use-case is to enable browsers to read icy metadata via a cross-origin request. I'm building a client side library that does that here: [icecast-metadata-js](https://github.com/eshaz/icecast-metadata-js). The inline metadata offers immediate metadata updates with no noticeable latency, which is really valuable in certain contexts, like for broadcasting police / fire scanner metadata, or ad insertions, etc.
[0001-feat-add-icy-metadata-support-for-cors.patch](/uploads/fb696baa19b3dfe8419021d66d52e2a3/0001-feat-add-icy-metadata-support-for-cors.patch)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2378There should be a stats value indicating how if a stream is in a stable state2022-02-27T20:06:54ZPhilipp SchafftThere should be a stats value indicating how if a stream is in a stable stateThere should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flap...There should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flapping stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2408Rename <no-mount>2022-02-28T10:58:49ZPhilipp SchafftRename <no-mount>The config option `<no-mount>` should be renamed to have some better name.
One of the suggestions was `<allow-direct-access>` (which has inverted logic).The config option `<no-mount>` should be renamed to have some better name.
One of the suggestions was `<allow-direct-access>` (which has inverted logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2409The <no-mount> flag should be visible at the status page2022-02-28T11:17:41ZPhilipp SchafftThe <no-mount> flag should be visible at the status pageThe `<no-mount>` flag should be visible at the status page. At least the player and the playlist links should be removed.The `<no-mount>` flag should be visible at the status page. At least the player and the playlist links should be removed.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2099Review how Icecast binds to sockets (IPv6/IPv4)2022-03-07T10:07:56ZThomas B. RückerReview how Icecast binds to sockets (IPv6/IPv4)The current behaviour, as introduced after considerable research and discussion neeeds to be reviewed.
Either we should bind to *both* if no IP nor protocol is specified or we MUST document this better and change the default config to e...The current behaviour, as introduced after considerable research and discussion neeeds to be reviewed.
Either we should bind to *both* if no IP nor protocol is specified or we MUST document this better and change the default config to explicitly bind to both.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2383Oversized EBML headers for WebM live stream2022-03-09T19:32:39ZWolne WilnoOversized EBML headers for WebM live streamFrom version ffmpeg 4.1 or above, when trying to stream WebM video Icecast produce error: `EBML Header too large, failing`
Solution is to increase EBML Header in `format_ebml.c` from 131072 bytes (0.125 MiB) to bytes 524288 (0.5 Mib)
C...From version ffmpeg 4.1 or above, when trying to stream WebM video Icecast produce error: `EBML Header too large, failing`
Solution is to increase EBML Header in `format_ebml.c` from 131072 bytes (0.125 MiB) to bytes 524288 (0.5 Mib)
Change in https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/src/format_ebml.c from `#define EBML_HEADER_MAX_SIZE 131072` to `#define EBML_HEADER_MAX_SIZE 524288`https://gitlab.xiph.org/xiph/icecast-server/-/issues/2360Document and define query string and POST parameters2022-03-11T12:47:10ZPhilipp SchafftDocument and define query string and POST parametersThe currently existing parameters should be documented.
Also it should be one or more or a prefix for custom parameters be defined for user specific data.
* The value(s) should be send to logging,
* the value(s) should be send to auth,
...The currently existing parameters should be documented.
Also it should be one or more or a prefix for custom parameters be defined for user specific data.
* The value(s) should be send to logging,
* the value(s) should be send to auth,
* the value(s) may be send to (fast)events.
A single value like 'token' or 'etoken' (e ➔ external) would be easy and secure to implement. However a user that needs multiple values must encode them into a single value themselfs in that case.
On the other paw a prefix could be defined (such as 'e-', e ➔ external) that is considered 'safe' (as in not used by Icecast or any future version) even if not used. This would allow future extension at some point.
currently the following parameters are universal:
* omode
* mount
The admin/-interface uses more parameters.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2429/admin/version.xsl is not installed2022-03-15T10:23:11ZPhilipp Schafft/admin/version.xsl is not installed`/admin/version.xsl` is not installed. (Missing in `nobase_dist_admin_DATA`.)`/admin/version.xsl` is not installed. (Missing in `nobase_dist_admin_DATA`.)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1914Port wildcard mounts to trunk2022-03-15T11:05:26ZcatoPort wildcard mounts to trunkIn the [kh-branch](https://trac.xiph.org/browser/icecast/branches/kh/icecast/src/cfgfile.c#L1203) is a feature which allows you to specify wildcard mounts like
```
<mount>
<mount-name>/foo-*.mp3</mount-name>
</mount>
```
to set options f...In the [kh-branch](https://trac.xiph.org/browser/icecast/branches/kh/icecast/src/cfgfile.c#L1203) is a feature which allows you to specify wildcard mounts like
```
<mount>
<mount-name>/foo-*.mp3</mount-name>
</mount>
```
to set options for an unknown set of mount points. Please port this to the [mainstream icecast](https://trac.xiph.org/browser/icecast/trunk/icecast/src/cfgfile.c#L1126) as well.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2430The Playlist does not display the time the song was played.2022-03-15T15:11:37ZPhilipp SchafftThe Playlist does not display the time the song was played.The playlist currently adheres XSPF fully, so there are no timestamps. However it might be useful. It may be added using extentions (likely using a `<meta>` element).
See also parent ticket #2428.The playlist currently adheres XSPF fully, so there are no timestamps. However it might be useful. It may be added using extentions (likely using a `<meta>` element).
See also parent ticket #2428.https://gitlab.xiph.org/xiph/icecast-server/-/issues/1655OggFLAC metadata not supported in Icecast2022-03-16T01:33:34ZJim CollinsonOggFLAC metadata not supported in IcecastAs a business we would really like to start streaming in lossless OggFLAC, but Icecast does not support metadata from OggFLAC. So this is a no-go for us at the moment.
FLAC uses Vorbis comments, so surly this wouldn't be difficult to ac...As a business we would really like to start streaming in lossless OggFLAC, but Icecast does not support metadata from OggFLAC. So this is a no-go for us at the moment.
FLAC uses Vorbis comments, so surly this wouldn't be difficult to achieve?Philipp SchafftPhilipp Schafft