Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2023-06-22T08:22:35Zhttps://gitlab.xiph.org/xiph/icecast-website/-/issues/2053Poor contrast on main page2023-06-22T08:22:35ZTerence EdenPoor contrast on main pageThe following text is very hard to read due to low contrast between in and the background colour.
![low contrast warning](/uploads/55b8e6125728c00fc6c7312c615116b1/contrast.png)
> is free server software for streaming multimedia.
This...The following text is very hard to read due to low contrast between in and the background colour.
![low contrast warning](/uploads/55b8e6125728c00fc6c7312c615116b1/contrast.png)
> is free server software for streaming multimedia.
This is caused by the `h1` style in https://gitlab.xiph.org/xiph/icecast-website/-/blob/master/assets/css/style.css#L334
I suggest changing it from `#29495C` to `#CAD5DB` which is the background colour of the main page.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/opus/-/issues/2329Any plans to make new release?2023-04-20T23:34:55ZTomasz KłoczkoAny plans to make new release?Looks like it is alread +600 commits since last release +year ago.
I think that it would be good to flush currently committed changes and make new release :)Looks like it is alread +600 commits since last release +year ago.
I think that it would be good to flush currently committed changes and make new release :)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2391Found memory leak problems on ubuntu 20.04 tls2024-01-21T02:16:55ZChaichanaFound memory leak problems on ubuntu 20.04 tlsubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applica...ubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applications
https://mediarealm.com.au/articles/icecast-https-ssl-setup-lets-encrypt/
- IMAGE
Top in image ubuntu 18.04 tls
Bottom in image ubuntu 20.04 tls
![ฟ](/uploads/d236d04fa7fc56f7c97c7d47e7937a12/ฟ.jpg)https://gitlab.xiph.org/xiph/opus/-/issues/2328cmake - intrinsics is not enabled for x86 for non windows due to missing defines2022-07-12T14:05:59ZMarcus Asteborgcmake - intrinsics is not enabled for x86 for non windows due to missing defineshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2317nanosleep patch2020-10-21T08:51:08ZRosen Penevnanosleep patchI can't create a merge request so here's a patch:
```
From 4467530c2396c61e886bf2dc4563be0e9c54394b Mon Sep 17 00:00:00 2001
From: Rosen Penev <rosenp@gmail.com>
Date: Fri, 3 Apr 2020 19:32:39 -0700
Subject: [PATCH] nonblocking: remove ...I can't create a merge request so here's a patch:
```
From 4467530c2396c61e886bf2dc4563be0e9c54394b Mon Sep 17 00:00:00 2001
From: Rosen Penev <rosenp@gmail.com>
Date: Fri, 3 Apr 2020 19:32:39 -0700
Subject: [PATCH] nonblocking: remove usleep usage
usleep is deprecated under POSIX 2008 and is optionally unavailable
with uClibc-ng.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
examples/nonblocking.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/examples/nonblocking.c b/examples/nonblocking.c
index 8e38a94..2f15b80 100644
--- a/examples/nonblocking.c
+++ b/examples/nonblocking.c
@@ -70,8 +70,10 @@ int main()
if (ret == SHOUTERR_BUSY)
printf("Connection pending...\n");
+ const struct timespec req = {0, 10 * 1000 * 1000};
+ struct timespec rem;
while (ret == SHOUTERR_BUSY) {
- usleep(10000);
+ nanosleep(&req, &rem);
ret = shout_get_connected(shout);
}
--
2.26.2
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2390status-json with fallback-mount2020-08-31T15:48:47ZIgor dWstatus-json with fallback-mountI have icecast 2.4.4 with win2016 server. I'm using a fallback-mount. When the fallback mount is active my player gets the metadata from this mount and works perfect. When the 'main' mount gets active, icecast switches perfect, and in my...I have icecast 2.4.4 with win2016 server. I'm using a fallback-mount. When the fallback mount is active my player gets the metadata from this mount and works perfect. When the 'main' mount gets active, icecast switches perfect, and in my status-json my 'main' mount is first presented so my player pickes te metadata correct. When the 'main' mount is lost and icecast switches to the fallback mount things go wrong. The music switches but in status-json the metadata from the 'main' mount is not dropped/removed so my player is looking to empty strings and is not presenting artist and song information. The 'main' mount is also not dropped in the icecast server status (but empty, containing no data). When i at this point also disconnect the fallback, both are removed from status-json. Is this a setting i have to change or a bug?
[Icecast_xml_settings.txt](/uploads/be6d02c1146dea8396b28c984b0178fa/Icecast_xml_settings.txt)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2389Infinite loop login/passwd when htpasswd is used2020-10-26T17:36:34ZtormyvancoolInfinite loop login/passwd when htpasswd is usedSetting up **Icecast 2.4.4** Windows version (**W7 64bit** and **HTTP** protocol (I don't use HTTPS)) I got a strange issue, not reported by the error.log
The created user, gets an infinite loop of LOGIN popups.
Writing the correct logi...Setting up **Icecast 2.4.4** Windows version (**W7 64bit** and **HTTP** protocol (I don't use HTTPS)) I got a strange issue, not reported by the error.log
The created user, gets an infinite loop of LOGIN popups.
Writing the correct login and password, the popup is always returned and the user never get access.
Even giving to the user a login string as http://user:password@My_Public_Ip:8000/stream (where **/stream** is my mountpoint)
- 8000 is the port I use
- It's opened in bidirectional way on my router and firewall
- protocols: TCP/UDP
Please here below just the lines for the auth
in attachment ou find my *icecast.xml* "anonymized", as requested by your Policies, and the chunck of the *error.log* where I got the infinite loop
It resulted impossible to use Login and Password (at the moment).
Users should be very limited, that's why I put just 3
The MyAuth file is correctly generated and managed bui the UI
```
<!-- Normal mounts -->
<mount type="normal">
<mount-name>/stream</mount-name>
<max-listeners>3</max-listeners>
<authentication type="htpasswd">
<option name="filename" value="myauth"/>
<option name="allow_duplicate_users" value="0"/>
</authentication>
</mount>
```
[icecast.xml](/uploads/48fd92adae020bc51b2ab90b14e816c4/icecast.xml)
[error.log](/uploads/debf531d6f79a2f2cfd0d73f9789a687/error.log)https://gitlab.xiph.org/xiph/vorbis/-/issues/2342Getting undefined reference to `_impure_ptr' on mingw compilation2020-07-08T14:20:51ZMoritz BenderGetting undefined reference to `_impure_ptr' on mingw compilationI downloaded the libvorbis-1.3.7 tarball because I wanted to statically compile it. Compiling on mingw fails, with the main error being this:
```
make[3]: Entering directory '/g/Downloads/libvorbis-1.3.7/lib'
CCLD test_sharedbook.e...I downloaded the libvorbis-1.3.7 tarball because I wanted to statically compile it. Compiling on mingw fails, with the main error being this:
```
make[3]: Entering directory '/g/Downloads/libvorbis-1.3.7/lib'
CCLD test_sharedbook.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: test_sharedbook-sharedbook.o:sharedbook.c:(.rdata$.refptr._impure_ptr[.refptr._impure_ptr]+0x0): undefined reference to `_impure_ptr'
collect2.exe: error: ld returned 1 exit status
```
Compilation did work on my wsl, so I'm not sure what this is about. I managed to get the static library by make -j ing, but I'd still like to know why this part fails and whether there is a way to avoid this.https://gitlab.xiph.org/xiph/opus-tools/-/issues/2314Release new version (and builds) with the libopusenc gapless bug fixed2020-07-05T02:18:05ZAmanRelease new version (and builds) with the libopusenc gapless bug fixedlibopusenc 0.2.1 includes xiph/libopusenc@a852e9fbfd7c360e9078d124e73ec6eef2665148, which fixed a bug with encoding tracks gaplessly. It will be great if you can cut a new release with this included.libopusenc 0.2.1 includes xiph/libopusenc@a852e9fbfd7c360e9078d124e73ec6eef2665148, which fixed a bug with encoding tracks gaplessly. It will be great if you can cut a new release with this included.https://gitlab.xiph.org/xiph/vorbis/-/issues/2341Broken MSDN links2020-07-04T02:02:58ZRalph GilesBroken MSDN linksThe api docs link to msdn.microsoft.com for details of how the Visual Studio 8 standard library handles stdin/out. Those links no longer work. They pages are still available through archive.org, but the docs should be reviewed to see if ...The api docs link to msdn.microsoft.com for details of how the Visual Studio 8 standard library handles stdin/out. Those links no longer work. They pages are still available through archive.org, but the docs should be reviewed to see if the details are still correct. Behaviour may well have changed in the intervening decade.https://gitlab.xiph.org/xiph/opusfile/-/issues/2328Release v0.122023-03-18T15:58:34ZRalph GilesRelease v0.12Tracking issue for the 0.12 release.Tracking issue for the 0.12 release.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2388Indefinite 100% CPU when disconnecting from SSL port when Icecast is running ...2021-01-23T08:17:31ZredactedscribeIndefinite 100% CPU when disconnecting from SSL port when Icecast is running inside a Podman container*UPDATE: This bug seems hard to track down and the solution as described below of spawning the Podman container as root rather than rootlessly doesn't actually work. It definitely seemed to be the fix last night, but I've now encountered...*UPDATE: This bug seems hard to track down and the solution as described below of spawning the Podman container as root rather than rootlessly doesn't actually work. It definitely seemed to be the fix last night, but I've now encountered the same high CPU usage problem that spawning as rootless was producing, but as root. Noteworthy is that I tested the same build process on the host system without containers, and the bug was no more, but judging how the bug has seemed to have has disappeared completely and then returned a few times, I'm not certain of the results. Leaving this report up as it could still lead to an answer.*
The easiest way for me to communicate the issue is through these steps:
- [Create a Let's Encrypt cert](https://certbot.eff.org/).
- Create `icecast.pem` using what Let's Encrypt produced: `fullchain.pem` + `privkey.pem`.
- Place `icecast.pem` into same dir as `Containerfile` and `entrypoint.sh` (attached files).
- [Install Podman](https://podman.io/getting-started/installation).
- As an unprivileged user, run: `podman build --force-rm -f Containerfile -t icecast`. This builds Icecast 2.4.4 from source with `--with-curl` and `--with-openssl` flags (`OpenSSL/1.1.1g` is what Alpine currently serves).
- Open ports `8000/tcp` and `8001/tcp` on the host if needed.
- Spawn an Icecast container (replace `<hostname>`):
```sh
podman run --rm --interactive --tty --publish 8000:8000 --publish 8001:8001 \
--env IC_HOSTNAME="<hostname>" \
--env IC_HTTP_PORT="8001" \
--env IC_HTTPS_PORT="8000" \
--env IC_LOG_LEVEL="4" \
--name icecast \
icecast
```
- To monitor Icecast's logs via the host, you can use `podman exec icecast tail /usr/local/var/log/icecast/access.log -f` and `podman exec icecast tail /usr/local/var/log/icecast/error.log -f`.
- Stream to the server's HTTPS port `8000` using a source client (in my case, Butt on Windows) with the default credentials.
- After connection, disconnect. `htop` on the host should now report 100% CPU for the container process, and reconnection via the source client should no longer be possible.
- Pressing `s` in `htop` on one of the two `icecast -c /usr/local/etc/icecast.xml` commands listed running at ~100% CPU, `strace` shows intense polling spam:
```sh
...
poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
read(7, read(7, read(7, read(7, ) = 1 ([{fd=7, revents=POLLIN}])
poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
read(7, "", 5) = 0
read(7, read(7, read(7, poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
...
```
For the other high CPU Icecast command, `strace` shows less spam:
```sh
...
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 300) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 300) = 0 (Timeout)
...
```
- With the container still running, running `podman exec icecast netstat -t` on the host shows Alpine waiting:
```sh
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 <hostname>:46372 <hostname>:8000 FIN_WAIT2
tcp 0 0 <hostname>:8000 <hostname>:46372 CLOSE_WAIT
netstat: /proc/net/tcp6: No such file or directory
```
It looks like the connection is never closed properly, as visiting `https://<hostname>:8000/admin/` and pressing `Kill Source` brings things back to normal. This is specifically confined to SSL as connecting to the HTTP port `8001` and then disconnecting has no adverse effects. Only the HTTPS port is affected.
~~The solution for me has been to spawn the Podman container as root rather than rootlessly. When doing so, Icecast doesn't get stuck in a loop waiting for the connection to drop after disconnection from HTTPS port (or whatever the exact issue is). Ideally, Icecast could function in a container run rootlessly as this is a major advantage of Podman's approach to containers over Docker's.~~
I am unsure if there is a bug on Podman's side (concerning container networking, or possible misconfiguration on my part), but I don't believe Icecast should be able to get stuck in this scenario producing 100% CPU indefinitely. Therefore, I have reported this here rather than to Podman.
Thanks.
Infos:
```
Icecast 2.4.4 (from source) running on Alpine inside the container
Podman 1.9.3
Fedora release 32 (Thirty Two)
Linux 5.6.19-300.fc32.x86_64
```
[icecast-indefinite-100_-cpu-bug-report.tar](/uploads/4840719fa9fe143617af35b9c78f6895/icecast-indefinite-100_-cpu-bug-report.tar)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2387listclients not working if authentication type is url2020-10-15T10:35:27Znaitsirchlistclients not working if authentication type is urlWe have configured our Icecast (v. 2.4.4) mount with stream_auth via URL. Authentication with the source client works well. But it is comming to a strange error when listener stats are requested with the source password.
This is our mou...We have configured our Icecast (v. 2.4.4) mount with stream_auth via URL. Authentication with the source client works well. But it is comming to a strange error when listener stats are requested with the source password.
This is our mount config:
```xml
<mount type="default">
<mount-name>/stream</mount-name>
<stream-name><![CDATA[Test]]></stream-name>
<authentication type="url">
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="stream_auth" value="https://my-authentication-provider.com/api/icecast/stream_auth"/>
</authentication>
</mount>
```
Streaming with butt and source password works as expected. So the authentication works.
Now, if I try to access the URL `/admin/listclients?mount=/stream` with the source password, to see the number of connected listeners. I get a *403 Forbidden* with the message `Mountpoint in use`.
This is the request that is sent by curl:
```
GET /admin/listclients?mount=/stream HTTP/1.1
Host: server34299.streamplus.de:10106
Authorization: Basic {...}
User-Agent: curl/7.64.0
Accept: */*
```
I have checked the base64 encoded username and password in the authentication header. It is the same that is used in the source client.
The response by Icecast is:
```
HTTP/1.0 403 Forbidden
Server: Icecast 2.4.4
Connection: Close
Date: Wed, 17 Jun 2020 11:58:06 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache, no-store
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
Mountpoint in use
```
If I remove the `<authentication type="url">` part of the config and restart the server, calling `/admin/listclients?mount=/stream` works as expected.
It looks like the listclients action has a bug if Icecast is running with stream_auth via URL. If you need any further information please let me know.
OS: Debian 10.4, Linux version 4.19.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
**Update:**
If I use the admin credentials to access the listener stats, it works as expected.https://gitlab.xiph.org/xiph/opus/-/issues/2327CMake - Consistent warning levels between autotools and cmake2020-08-08T17:36:52ZMarcus AsteborgCMake - Consistent warning levels between autotools and cmakeIf things blow up on automake it should blow up on cmakeIf things blow up on automake it should blow up on cmakehttps://gitlab.xiph.org/xiph/opus/-/issues/2326undefined behavior in silk_NSQ_del_dec_neon2020-06-14T07:36:42ZRalph Gilesundefined behavior in silk_NSQ_del_dec_neonCompiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behav...Compiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behavior [-Waggressive-loop-optimizations]
422 | NSQ->sLPC_Q14[ i ] = psDelDec->sLPC_Q14[ i ][ Winner_ind ];
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
silk/arm/NSQ_del_dec_neon_intr.c:421:9: note: within this loop
421 | for( ; i < NSQ_LPC_BUF_LENGTH; i++ ) {
| ^~~
```https://gitlab.xiph.org/xiph/opus/-/issues/2325float to short improvements2020-06-16T14:23:47ZMarcus Asteborgfloat to short improvements[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does S...[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does SSE2 even have a proper way to round without messing with rounding modeshttps://gitlab.xiph.org/xiph/libao/-/issues/2319When I try to fork Xiph.org/libao I get a "You have reached your project limits"2024-02-02T10:40:25ZGonzalo GarramunoWhen I try to fork Xiph.org/libao I get a "You have reached your project limits"When I try to fork Xiph.org/libao I get a "You have reached your project limits"
I would like to create a fork and set up a merge request please.When I try to fork Xiph.org/libao I get a "You have reached your project limits"
I would like to create a fork and set up a merge request please.https://gitlab.xiph.org/xiph/opus/-/issues/2324SILK complexity levels 1 and 2 are inconsistent2020-06-01T19:22:07ZFrancis QuiersSILK complexity levels 1 and 2 are inconsistentIn `silk_setup_complexity()`, it seems that the parameters chosen for complexity levels 2 and 3 are mostly swapped (except `nStatesDelayedDecision`)In `silk_setup_complexity()`, it seems that the parameters chosen for complexity levels 2 and 3 are mostly swapped (except `nStatesDelayedDecision`)https://gitlab.xiph.org/xiph/Infrastructure/-/issues/2232mf5 requirements2020-07-13T16:20:45ZRalph Gilesmf5 requirements# Xiph.Org Service Requirements
With the failure of mf4, we have a decision to make about where we want to run our services.
Most essential things have been migrated to catfish. For remaining bits, please add to the list below and help...# Xiph.Org Service Requirements
With the failure of mf4, we have a decision to make about where we want to run our services.
Most essential things have been migrated to catfish. For remaining bits, please add to the list below and help prioritize.
Several options going forward
- re-install mf4 from scratch, have backups for when it fails again.
- Buy a replacement server (or several).
- Must have remote console support.
- osuosl prefers Dell PowerEdge.
- Use osuosl's openstack cluster.
- Redundant storage (but no geographical replication)
- Don't have to maintain underlying hosts.
- Can still contribute, probably by buying drives for the Ceph cluster.
The raid failure demonstrates we've not been doing a good job with administration. Whatever we do going forward, we need to make sure we have automated offsite backups and that it's much easier to configure and upgrade our various services, ideally from deployment templates stored in version control. We should periodically practice service migration and restoration.
## static sites 🔶
- Partially restored from git or older svn backup + archive.org.
- Served as static html or shtml from catfish.
- Working on auto-deployment from gitlab ci.
- Should move remaining sites from svn to git.
- media.xiph.org is served from beaufish, and wasn't affected.
## dynamic websites
- gitlab.xiph.org ✅
- vm already on catfish
- wiki.xiph.org ✅
- vm aleady on catfish
- dir.xiph.org ✅
- switched to beta vm on catfish
- awcy ✅
- vm already on catfish
- svn.xiph.org
- down, lost data
- ftp.osuosl.org has a current snapshot of releases and websites
- people.xiph.org ❌
- down, lost data.
- planet.xiph.org
- anyone still blogging?
- jenkins ❌
- down, lost data.
- should replace with gitlab-ci.
- munin ❌
- down, not high priority.
- Better replacements?
- review.xiph.org 🔶
- down, have a recent backup.
- not actively used: not planning to restore.
## releases 🔶
- downloads.xiph.org redirects from catfish to ftp.osuosl.org
- ftp site has current files.
- was backed by svn, lost recent history.
- restore svn and re-populate from ftp.osuosl.org?
- alternate: git? gitlab artifacts? Some other object store?
## shell server
- Several people used shell accounts on mf4.
- Do we need to keep providing this?
- Alternate: per-user containers? kubernetes?
## email ✅
- mail and lists already on a catfish vm.
## dns 🔶
- catfish temporarily authoritative
- Need another machine to be secondary
- alternate: Use registrar or osuosl.https://gitlab.xiph.org/xiph/Infrastructure/-/issues/2231Update xiph.org/vorbis for gitlab2021-02-19T23:48:43ZRalph GilesUpdate xiph.org/vorbis for gitlabThe repo links still point to obsolete git.xiph.org, which has been down since the server crash.The repo links still point to obsolete git.xiph.org, which has been down since the server crash.