Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2017-10-05T10:40:40Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2259[PATCH] Master-Slave Aggregating Relay (multiple master setup)2017-10-05T10:40:40ZMarvin Scholz[PATCH] Master-Slave Aggregating Relay (multiple master setup)We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have a...We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have asked for this feature in the past and were referred to the Single-Broadcast Relay, which is OK provided you know the specific mountpoints that you want to relay ahead of time.
>
> If you are in a position where you want to relay mountpoints for more than one the master server, and one or more of the master servers adds and removes mountpoints dynamically or if you are unable to know what mountpoints are available ahead of time then this gives you the ability to aggregate all mountpoints for any numbers of master servers.
>
> Namespacing is also supported to prevent name clashes for mountpoints being relayed from different servers.
The patch can be found here:
```
https://github.com/xiph/Icecast-Server/pull/5.patch
```
For more information, see the [original Github Pull-Request](https://github.com/xiph/Icecast-Server/pull/5)!Icecast 2.5.2Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2246Check Icecast2 for support to whatever result of #22332018-06-16T21:36:36ZPhilipp SchafftCheck Icecast2 for support to whatever result of #2233Icecast2 should support whatever the outcome is to icecast-libshout#2233. This ticket should be updated once icecast-libshout#2233 is closed to list what needs to be done on the server side.Icecast2 should support whatever the outcome is to icecast-libshout#2233. This ticket should be updated once icecast-libshout#2233 is closed to list what needs to be done on the server side.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2237[PATCH] Detect Keyframes in WebM streams2018-03-06T12:49:37ZJoseph Wallace[PATCH] Detect Keyframes in WebM streamsThe existing WebM plugin will mark the start of any cluster as a sync point. This causes problems for web browsers, which tend to strictly demand that video streams are started on a keyframe.
The WebM specs call for a keyframe being the...The existing WebM plugin will mark the start of any cluster as a sync point. This causes problems for web browsers, which tend to strictly demand that video streams are started on a keyframe.
The WebM specs call for a keyframe being the first video frame in a cluster if the cluster contains a keyframe, but they do not require clusters to contain any keyframes at all.
This patchset:
1. implements some EBML parsing functions, to identify clusters accurately instead of assuming any occurrence of the cluster magic number is a cluster header.
2. detects if a WebM stream contains a track of type video.
3. examines the SimpleBlocks of each cluster to determine if the first video track block is marked as a keyframe.
If the first video block is a keyframe, the cluster is marked as a sync point. If the first video block is NOT a keyframe, the cluster is not marked as a sync point.
If a determination cannot be made in the first 4K of the cluster, it's optimistically marked as a sync point, since it's most likely an audio-only stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2200icecast stats addition (per mount cumulative listener counter)2018-07-07T09:19:54Zddndukkicecast stats addition (per mount cumulative listener counter)Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
s...Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
so it appears in /icecasts/source/ node with name like 'listener_connections'.
<icestats>
<listener_connections>3</listener_connections>
<source mount="/test">
<listener_connections>2</listener_connections>
...
</source>
</icecasts>
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2183Adjust Icecast's Auth Realm2021-10-30T09:32:58ZMarvin ScholzAdjust Icecast's Auth RealmCurrently Icecast is using the following header for telling the server how to do auth:
`WWW-Authenticate: Basic realm="Icecast2 Server"`
The Auth realm name should probably adjusted to just one of the following:
- 'Icecast Server'
- '...Currently Icecast is using the following header for telling the server how to do auth:
`WWW-Authenticate: Basic realm="Icecast2 Server"`
The Auth realm name should probably adjusted to just one of the following:
- 'Icecast Server'
- 'Icecast 2 Server'
- 'Icecast Admin Interface'
- value of server name + ' Server'
(please leave a comment which one you would go for, even better if you have a good reason for it)Icecast 3.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2180SSL for admin only2020-10-15T09:24:19ZMelvyn SopacuaSSL for admin onlyHi,
I've tried the configuration below to setup SSL for the admn. This doesn't work and the documentation is too tierse to give me any hints.
Goal: Force and use SSL for /admin mountpoint. This needs to be a different URL (certificate ...Hi,
I've tried the configuration below to setup SSL for the admn. This doesn't work and the documentation is too tierse to give me any hints.
Goal: Force and use SSL for /admin mountpoint. This needs to be a different URL (certificate has limited hostnames)
Configuration tried:
```
<mount>
<mount-name>/admin</mount-name>
<ssl>1</ssl>
<stream-url>https://www.example.com:8000/admin</stream-url>
</mount>
```
Result:
1. Admin is accessible through HTTP
2. No secure connection can be established through HTTPS.
Note: firewall is not in play, because of 1), but verified regardless.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2175Url auth with HTTPS on Win not working2022-03-21T09:31:08ZSebastianUrl auth with HTTPS on Win not workingHi guys,
i tried url auth yesterday with an https link on windows.
I get this error here:
```
[2015-03-12 16:55:20] WARN auth_url/auth_url.c auth to server https://www.domain.com/auth.php failed with Problem with the SSL CA cert (pat...Hi guys,
i tried url auth yesterday with an https link on windows.
I get this error here:
```
[2015-03-12 16:55:20] WARN auth_url/auth_url.c auth to server https://www.domain.com/auth.php failed with Problem with the SSL CA cert (path? access rights?)
```
With this configuration:
```
<mount type="normal">
<mount-name>/radio</mount-name>
<max-listeners>10</max-listeners>
<username>...</username>
<password>...</password>
<authentication type="url">
<option name="listener_add" value="http://www.domain.com/auth.php"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
</mount>
```
I know that you have tried to make it run for windows. I just wanted to keep it tracked here.
Comments/ideas from tbr to that:
"it is working fine on linux. It might work on windows, but nobody figured out how to feed the CA path or file to the curl/nss combination."
"if someone figures out how OR if I switch to Fedora as the build distro, then it /might/ you're free to build on fedora, then it would link against an openssl curl and that might work, or not."
Thanks.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2168Icecast should expose the YP server messages to the admin status pages per mount2018-06-16T22:44:50ZThomas B. RückerIcecast should expose the YP server messages to the admin status pages per mountThere are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simp...There are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simplified status should be also exposed to the XML used for public status.
People don't read the error.log, ever, especially in this case.
We should expose:
* If the YP server accepted the initial touch
* If the server accepted the latest touch
* What was the last status message from the YP server for a failed touch
* What was the latest status message from the YP server, including successful
* Count of YP touches since source connection
* Count of failed YP touches since source connection
Rationale is, that there might be intermittent failures so we should expose both latest message and latest failure. Also latest message, if successful could contain some information like "server outdated and insecure, please update" or otherwise from the YP administration.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2167Icecast should expose the YP listing status to the public status pages2018-06-16T22:44:16ZThomas B. RückerIcecast should expose the YP listing status to the public status pagesThere are hundreds if not thousands of streams that fail to list properly in dir.xiph.org and it's obvious that nobody notices.
/admin/stats should expose a per mount status field if the given mount is set public and directory listings ...There are hundreds if not thousands of streams that fail to list properly in dir.xiph.org and it's obvious that nobody notices.
/admin/stats should expose a per mount status field if the given mount is set public and directory listings are enabled for the server.
Logic could be as follows:
* *OK* - No known errors for this mount
* *WARN* - During the last n yp-touches at least one error was received
* *FAIL* - No successful listing/touch for this mount
Further information, including verbatim messages from YP should be available through the admin interface. Covered in a separate ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2156Check feasibility of intro functionality for WebM2018-03-06T12:49:38ZThomas B. RückerCheck feasibility of intro functionality for WebMSee #2155 also #1941
We would need to see if an otherwise parameter compatible stream can be spliced seamlessly so that it doesn't cause players to complain/break.
If not feasible we should disable intro if content-type is WebM.See #2155 also #1941
We would need to see if an otherwise parameter compatible stream can be spliced seamlessly so that it doesn't cause players to complain/break.
If not feasible we should disable intro if content-type is WebM.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2155Improve WebM support in Icecast2019-06-26T17:23:33ZThomas B. RückerImprove WebM support in IcecastWe currently don't support the same use-cases as other formats.
This is partly due to the format - WebM doesn't support something like chaining.
We might work around a few things, but this needs to be explored.
This is a tracker ticket.We currently don't support the same use-cases as other formats.
This is partly due to the format - WebM doesn't support something like chaining.
We might work around a few things, but this needs to be explored.
This is a tracker ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2150check if we need to forward port a possible win32 security fix from kh2020-10-15T11:20:19ZThomas B. Rückercheck if we need to forward port a possible win32 security fix from khhttps://github.com/karlheyes/icecast-kh/commit/b50c6374234154ad94b3c3a3e76545601e997739
```
do not use SO_REUSEADDR on windows, breaks the reload handling
MS defined SO_REUSEADDR differently to BSD and linux and have allowed some stupi...https://github.com/karlheyes/icecast-kh/commit/b50c6374234154ad94b3c3a3e76545601e997739
```
do not use SO_REUSEADDR on windows, breaks the reload handling
MS defined SO_REUSEADDR differently to BSD and linux and have allowed some stupid
security issue on it for port stealing. They messed it up, added another option
which doesn't help here and advise not using this option. Luckily the default
behaviour is acceptable. I've also avoided the abort case which should not trigger
but if it does, it reports an error and skips the rest.
```
Needs checking against Windows documentation. There might be some differences in how kh and we use things.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2145Adding <outro> file for mountpoints2018-03-06T12:49:38ZJordan EricksonAdding <outro> file for mountpointsHello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are...Hello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are moved to. Thank you for your consideration =)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2138VCLT support in current icecast is useless2018-03-06T12:49:38ZPhilipp SchafftVCLT support in current icecast is uselessIn current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visib...In current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visible as the other formats OR
1. disable it by removing the code to avoid any maintenance need in future releases.
dm8tbr acknowledged to take a decision on this before final release of 2.5.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2127Icecast needs a web-UI for configuration2018-03-06T12:49:38ZThomas B. RückerIcecast needs a web-UI for configurationThere are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an exis...There are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an existing open source project.
There are two possible approaches:
* Internal (somehow as part of /admin)
* External (running on a proper web server)
The former would make it self-contained, while the latter would enable us to leverage an existing framework.
Both approaches need to be explored before a decision is made.
PS: Being fairly self-contained this would be potentially a very good GSoC or similar project. I am also sufficiently familiar with the config file and live config mechanics to mentor such a task.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2119Filter based on User Agent2018-11-10T13:31:06ZPhilipp SchafftFilter based on User AgentThere is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds ...There is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds of client data as well.
The module would return `NOMATCH` on no match or `FAILED` on match on deny list. Behaviour on pass should maybe be documented. Defaulting to `NOMATCH` to continue with the processing of other `<role>`s.
Some technical background:
In contrast to the `<allow-ip>` and `<deny-ip>` this check can only happen after the client request has been parsed as it depends on data of exactly this client request. This makes it less suitable for (D)DoS protection in general. It should be considered to use some kind of firewalling of fail2ban to protect against such attacks.
Pros of implementing it the way described above:
- It would match the internal schemata and wouldn't be another alien.
- It could be extended to universally match any configured attributes of the client object.
- Integrates well into usage together with other `<role>`s. E.g. to allow some role access but deny others access depending on this module (admin can always go, listeners only if user agent matches).
- Rejects the client with a `401` according to the standard.
Contra:
- Is much slower than implementing it in a specific and specific way as it happens in the authentication engine and not in before on rejected clients. Slowdown for passing clients will not be significant.
- Rejects clients with a standard conforming `401`. Does not just drop them.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2117Creating a policy for removing support for obsoleted features/interfaces2018-06-16T22:40:11ZPhilipp SchafftCreating a policy for removing support for obsoleted features/interfacesThere needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move th...There needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move the internals away from how 2.3.2 was. Such a policy will help much to avoid keeping workarounds for older ways of doing stuff in the codebase and will be a major improvement to the code quality and maintainability.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2110Timer-based functionalities should use single timer thread2022-05-16T23:03:32ZMarvin ScholzTimer-based functionalities should use single timer thread>all timer-based functionality (yp updates, slave/relay checks) should have a
>single timer thread which dispatches events through the normal event
>mechanism (to worker threads from the main pool). This will reduce the
>extraneous threa...>all timer-based functionality (yp updates, slave/relay checks) should have a
>single timer thread which dispatches events through the normal event
>mechanism (to worker threads from the main pool). This will reduce the
>extraneous thread count.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2109Abstract admin functionality to set of commands and handlers2020-10-15T09:20:39ZMarvin ScholzAbstract admin functionality to set of commands and handlers>abstract all admin functionality to a set of commands, and command handlers.
>
>Make /admin/* just parse according to a set of rules, and dispatch generic
>commands through that.
>
>Use this for alternative admin interfaces (GUI? telnet...>abstract all admin functionality to a set of commands, and command handlers.
>
>Make /admin/* just parse according to a set of rules, and dispatch generic
>commands through that.
>
>Use this for alternative admin interfaces (GUI? telnet interface?)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2107Provide a way for YP Dirs to check streams2020-10-15T11:58:06ZMarvin ScholzProvide a way for YP Dirs to check streams>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should b...>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should be a proper way to check if a stream is still reachable and running (and even maybe fetch updated metadata while at it).
This could be solved by implementing HTTP 1.1 HEAD and setting some headers, or as the TODO suggest, making a dedicated endpoint for it.Thomas B. RückerThomas B. Rücker