Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-05-06T20:21:09Zhttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/9Add / as Genre seperator2020-05-06T20:21:09ZAndreas MiekeAdd / as Genre seperatorSome stations seem to use / as genre seperator insted of , or space.
![Problem](/uploads/35fe7ea8c6e0024cd70a04f29f0c100e/image.png)Some stations seem to use / as genre seperator insted of , or space.
![Problem](/uploads/35fe7ea8c6e0024cd70a04f29f0c100e/image.png)1.0.0Andreas MiekeAndreas Miekehttps://gitlab.xiph.org/xiph/ezstream/-/issues/2269error -3: Login failed when trying to run multiple instances of ezstream2023-02-19T15:45:02ZDan Steingarterror -3: Login failed when trying to run multiple instances of ezstreamquick thank you for writing such great software.
I am attempting to serve multiple files on multiple mount points to a single `icecast2` server instance. The first connection succeeds as expected, but the subsequents attempts fail with ...quick thank you for writing such great software.
I am attempting to serve multiple files on multiple mount points to a single `icecast2` server instance. The first connection succeeds as expected, but the subsequents attempts fail with
`ezstream[9770]: stream: default: connect: [localhost]:8000: error -3: Login failed`
when I use an `xml` configuration file structured as
```
<ezstream>
<servers>
<server>
<hostname>localhost</hostname>
<password>hackme</password>
</server>
</servers>
<streams>
<stream>
<mountpoint>/stream_x</mountpoint>
<format>MP3</format>
</stream>
</streams>
<intakes>
<intake>
<filename>file_x.mp3</filename>
</intake>
</intakes>
</ezstream>
```
where `x` above is a unique file for a unique stream. Thanks.Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/8Search functionality2020-05-06T20:28:01ZAndreas MiekeSearch functionalityHow exactly should the search work? Currently there is only one query parameter which uses LIKE queries on the Name and Description fields to find streams. Is any filtering by codec/genre or simliar planned. Or: How exactly does the curr...How exactly should the search work? Currently there is only one query parameter which uses LIKE queries on the Name and Description fields to find streams. Is any filtering by codec/genre or simliar planned. Or: How exactly does the current search work?
@ePirat1.0.0Andreas MiekeAndreas Miekehttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/7Stream de-duplication2020-05-06T20:29:48ZAndreas MiekeStream de-duplicationHow should stream de-duplication work? Currently there is a unique_index on the Stream Name and Bitrate database fields, for which I got inspired by the old new directory.
Are there any concerns or improvements?
@ePiratHow should stream de-duplication work? Currently there is a unique_index on the Stream Name and Bitrate database fields, for which I got inspired by the old new directory.
Are there any concerns or improvements?
@ePirat1.0.0Andreas MiekeAndreas Miekehttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/6Do not overwrite config on exit2020-05-03T21:05:35ZMarvin ScholzDo not overwrite config on exitCurrently on exit the program will write its config, which can overwrite changes made to the config since the program was started.Currently on exit the program will write its config, which can overwrite changes made to the config since the program was started.1.0.0Andreas MiekeAndreas Miekehttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/5More detailed logging2020-05-06T22:20:10ZMarvin ScholzMore detailed loggingAdd the ability to log debug, warning, error messages to a file.
Especially for server YP listing failures it would be interesting to log the failure cases together with more information about the exact request data the server made (so ...Add the ability to log debug, warning, error messages to a file.
Especially for server YP listing failures it would be interesting to log the failure cases together with more information about the exact request data the server made (so it can be replicated) and the external and internal failure reason.
Probably best to use some logging framework to simplify that.1.0.0Andreas MiekeAndreas Miekehttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/4Fix search template on error pages2020-05-03T20:49:20ZAndreas MiekeFix search template on error pagesFix wrong search template on errors.Fix wrong search template on errors.1.0.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/3Genre with / (slash) breaks URLs2020-05-03T20:59:52ZAndreas MiekeGenre with / (slash) breaks URLsTemplate does not encode slashes in Genre URLs
`http://dir.xiph.org/genres/N/A`
Also accessing these genres seems to not work when slash is encoded correctly
`http://dir.xiph.org/genres/N%2FA`Template does not encode slashes in Genre URLs
`http://dir.xiph.org/genres/N/A`
Also accessing these genres seems to not work when slash is encoded correctly
`http://dir.xiph.org/genres/N%2FA`1.0.0Andreas MiekeAndreas Miekehttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/2yp.xml: Cache cuts off random parts2023-06-23T09:36:30ZAndreas Miekeyp.xml: Cache cuts off random partsCurrent caching module cuts off random parts of yp.xmlCurrent caching module cuts off random parts of yp.xml1.0.0Andreas MiekeAndreas Miekehttps://gitlab.xiph.org/xiph/XiphDirectory/-/issues/1Add Pagination for Genre/Codec/Search pages2023-06-23T22:30:19ZMarvin ScholzAdd Pagination for Genre/Codec/Search pagesPagination is needed, as on the real dataset there will be thousands of streams and outputting all on one page
is not going to perform well.
Either do a cursor-based pagination or an offset based one. Likely cursor based is going to wor...Pagination is needed, as on the real dataset there will be thousands of streams and outputting all on one page
is not going to perform well.
Either do a cursor-based pagination or an offset based one. Likely cursor based is going to work better performance wise
and additionally is better for consistency for things like the search where the dataset can change before the next
request is made and just using an offset would lead to confusing results.1.0.0Andreas MiekeAndreas Miekehttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/2322SIGUSR1 triggers resample & encoder initialising2020-03-25T23:20:09ZJonas LiljestrandSIGUSR1 triggers resample & encoder initialisingHi,
I'm having a bit of trouble with glitching audio when the metadata is updated
which I suspect is caused by using the encode feature.
In the logfile I see this
```
[2020-03-25 23:11:43] INFO signals/signal_usr1_handler Metadata u...Hi,
I'm having a bit of trouble with glitching audio when the metadata is updated
which I suspect is caused by using the encode feature.
In the logfile I see this
```
[2020-03-25 23:11:43] INFO signals/signal_usr1_handler Metadata update requested
[2020-03-25 23:11:43] INFO metadata/metadata_thread_signal tag 1 is artist=Some artist
[2020-03-25 23:11:43] INFO metadata/metadata_thread_signal tag 2 is title=Some title
[2020-03-25 23:11:43] INFO metadata/metadata_thread_signal Updating metadata
[2020-03-25 23:11:43] INFO audio/resample_initialise Initialised resampler for 2 channels, from 48000 Hz to 44100 Hz
[2020-03-25 23:11:43] INFO encode/encode_initialise Encoder initialising in VBR mode: 2 channel(s), 44100 Hz, quality
```
Here is my full `ices.xml`
```
<ices>
<background>0</background>
<logpath>/home/pi/ices/</logpath>
<logfile>ices.log</logfile>
<logsize>2048</logsize>
<loglevel>3</loglevel>
<consolelog>0</consolelog>
<pidfile>/home/pi/ices/ices.pid</pidfile>
<stream>
<instance>
<hostname></hostname>
<port>8000</port>
<password></password>
<mount>/radio.ogg</mount>
<reconnectdelay>2</reconnectdelay>
<reconnectattempts>5</reconnectattempts>
<maxqueuelength>80</maxqueuelength>
<encode>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<resample>
<in-rate>48000</in-rate>
<out-rate>44100</out-rate>
</resample>
</instance>
<input>
<module>stdinpcm</module>
<param name="rate">48000</param>
<param name="channels">2</param>
<param name="metadata">1</param>
<param name="metadatafilename">/var/ices2/tmp/metadata</param>
</input>
</stream>
</ices>
```
I start ices2 with the following command.
```
arecord -D plughw:1 --channels 2 --format dat -t raw | ices2 ices/ices.xml
```
Which logs
```
Recording raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
```https://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/ezstream/-/issues/2268libtag_c not recognized2022-08-20T02:49:50ZDigitalBox98libtag_c not recognizedAll dependencies were installed :
sudo apt-get install libshout3-dev libxml2-dev libtag1-dev libshout3-dev libvorbis-dev libogg-dev check libtag-extras-dev libtagc0-dev
However when launching configure, the libtag_c error below is raise...All dependencies were installed :
sudo apt-get install libshout3-dev libxml2-dev libtag1-dev libshout3-dev libvorbis-dev libogg-dev check libtag-extras-dev libtagc0-dev
However when launching configure, the libtag_c error below is raised :
./configure
checking tag_c.h usability... yes
checking tag_c.h presence... yes
checking for tag_c.h... yes
checking if libtag_c works... no
checking if libtag_c works with -ltag -lstdc++ -lz... no
checking for libtag_c... no
configure: error: libtag_c is missingMoritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2267Make fails with undefined references in function "_stream_cfg_tls"2022-08-20T02:55:19ZChris WoodsMake fails with undefined references in function "_stream_cfg_tls"Attempting to compile ezstream from either the latest master or develop branch on CentOS 7, with libshout 2.4.3 (compiled from source) and other packages like libtag from repo. Autoconf and configure are happy, however every time make fa...Attempting to compile ezstream from either the latest master or develop branch on CentOS 7, with libshout 2.4.3 (compiled from source) and other packages like libtag from repo. Autoconf and configure are happy, however every time make fails on TLS checks:
```
./.libs/libezstream.a(stream.o): In function `_stream_cfg_tls':
./installers/ezstream-develop/src/stream.c:134: undefined reference to `shout_set_tls'
./installers/ezstream-develop/src/stream.c:146: undefined reference to `shout_set_ca_directory'
./installers/ezstream-develop/src/stream.c:160: undefined reference to `shout_set_ca_file'
./installers/ezstream-develop/src/stream.c:174: undefined reference to `shout_set_client_certificate'
./installers/ezstream-develop/src/stream.c:183: undefined reference to `shout_set_allowed_ciphers'
```
OpenSSL 1.0.2k-fips installed, again from repo.Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/opus/-/issues/2321.exe opens CMD and closes it.2020-06-13T22:50:59ZJose.exe opens CMD and closes it.How can I even open the .exe when it closes right after?How can I even open the .exe when it closes right after?https://gitlab.xiph.org/xiph/theora/-/issues/2311Files produced by encoder_example are not properly muxed2020-03-05T22:05:53ZTristan MatthewsFiles produced by encoder_example are not properly muxedTo reproduce:
```
$> ./encoder_example ~/Videos/akiyo_qcif.y4m -o akiyo.ogv
$> ffplay akiyo.ogv
[ogg @ 0x7f0448000bc0] Broken file, keyframe not correctly marked.
Input #0, ogg, from 'akiyo.ogv':
Duration: 00:00:10.01, start: 0.00000...To reproduce:
```
$> ./encoder_example ~/Videos/akiyo_qcif.y4m -o akiyo.ogv
$> ffplay akiyo.ogv
[ogg @ 0x7f0448000bc0] Broken file, keyframe not correctly marked.
Input #0, ogg, from 'akiyo.ogv':
Duration: 00:00:10.01, start: 0.000000, bitrate: 66 kb/s
Stream #0:0: Video: theora, yuv420p, 176x144 [SAR 128:117 DAR 1408:1053], 29.97 tbr, 29.97 tbn, 29.97 tbc
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
...
```
Relevant parsing code from libavformat:
https://github.com/FFmpeg/FFmpeg/blob/e27a35e0458224ef6f47753f248ba84ec8284818/libavformat/oggdec.c#L783Tristan MatthewsTristan Matthewshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2382Streaming over SSL disconnects2020-10-02T13:45:10ZcyberStreaming over SSL disconnectsHi,
ERROR:
Feb 25 13:27:39 hostname kernel: icecast[550]: segfault at 7f2b7fe74000 ip 00007f2b7faa3a56 sp 00007ffef066b1a0 error 4 in libcrypto.so.1.0.1e[7f2b7fa2d000+1ba000]
Feb 25 17:22:07 hostname kernel: icecast[21702]: segfault at ...Hi,
ERROR:
Feb 25 13:27:39 hostname kernel: icecast[550]: segfault at 7f2b7fe74000 ip 00007f2b7faa3a56 sp 00007ffef066b1a0 error 4 in libcrypto.so.1.0.1e[7f2b7fa2d000+1ba000]
Feb 25 17:22:07 hostname kernel: icecast[21702]: segfault at 7f31c0de6000 ip 00007f31c0a15a56 sp 00007fff82c831f0 error 4 in libcrypto.so.1.0.1e[7f31c099f000+1ba000]
We have a station configured with icecast with SSL and has random disconnections.
Versions:
/usr/local/bin/icecast -v
Icecast 2.4.4
OpenSSL 1.0.1e-fips 11 Feb 2013
CentOS release 6.10
Centova Cast 3.2.10.20170725.stable-519r4029
Does anyone know if there is any way to solve this?
All I have found is this link but there is no solution in this regard:
https://gitlab.xiph.org/xiph/icecast-server/issues/2283
Kind regards,https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2316Cannot connect to server in nonblocking mode ("Please retry current operation.")2022-04-12T11:02:45ZTomasz LemiechCannot connect to server in nonblocking mode ("Please retry current operation.")After reenabling nonblocking sockets by applying the fix (workaround?) described in https://gitlab.xiph.org/xiph/icecast-libshout/issues/2315 the client is unable to connect to the server at all. HTTP request is sent, but the client clos...After reenabling nonblocking sockets by applying the fix (workaround?) described in https://gitlab.xiph.org/xiph/icecast-libshout/issues/2315 the client is unable to connect to the server at all. HTTP request is sent, but the client closes the connection before the reply arrives.
```
$ ./nonblocking
Error connecting: Please retry current operation.
```
strace shows the following:
```
$ strace -e connect,fcntl,fcntl64,select ./nonblocking
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(5, [4], [4], [4], {tv_sec=0, tv_usec=1000}) = 1 (out [4], left {tv_sec=0, tv_usec=999})
select(5, NULL, [4], NULL, {tv_sec=0, tv_usec=0}) = 1 (out [4], left {tv_sec=0, tv_usec=0})
select(5, [4], NULL, [4], {tv_sec=0, tv_usec=1000}) = 0 (Timeout)
Error connecting: Please retry current operation.
+++ exited with 0 +++
```
The third `select` call times out. Backtrace at this `select` call:
```
#0 __GI___select (nfds=5, readfds=readfds@entry=0x7fffffffc6c0, writefds=writefds@entry=0x0,
exceptfds=exceptfds@entry=0x7fffffffc7c0, timeout=timeout@entry=0x7fffffffc6b0) at ../sysdeps/unix/sysv/linux/select.c:39
#1 0x00007ffff7f78f3e in shout_connection_iter__wait_for_io (con=con@entry=0x55555555aa10, for_write=for_write@entry=0,
timeout=timeout@entry=0, shout=0x55555555a490, for_read=1) at connection.c:144
#2 0x00007ffff7f7961c in shout_connection_iter__message (shout=0x55555555a490, con=0x55555555aa10) at connection.c:374
#3 shout_connection_iter (shout=<optimized out>, con=<optimized out>) at connection.c:478
#4 shout_connection_iter (con=con@entry=0x55555555aa10, shout=shout@entry=0x55555555a490) at connection.c:442
#5 0x00007ffff7f77571 in try_connect (self=self@entry=0x55555555a490) at shout.c:1333
#6 0x00007ffff7f77752 in shout_open (self=0x55555555a490) at shout.c:189
#7 0x000055555555529b in main () at nonblocking.c:66
```
As a result of this timeout, `shout_connection_iter__wait_for_io` returns `SHOUT_RS_TIMEOUT` to `shout_connection_iter__message`, which then gets propagated back to `shout_connection_iter`. Now due to the following condition in `__iter` macro:
```C
case SHOUT_RS_TIMEOUT: \
case SHOUT_RS_NOTNOW: \
if (con->nonblocking == SHOUT_BLOCKING_NONE) \
return SHOUTERR_RETRY; \
retry = 1; \
```
`SHOUTERR_RETRY` is returned from `shout_connection_iter` and propagated back via `try_connect` and `shout_open` to the caller, which is usually not prepared to handle this value (it expects `SHOUTERR_SUCCESS`, `SHOUTERR_CONNECTED` or `SHOUTERR_BUSY`).
A one-line fix to the above:
```C
if (con->nonblocking == SHOUT_BLOCKING_NONE) \
return SHOUTERR_BUSY; \
```
fixes the problem.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2315Network socket not set to nonblocking mode despite using nonblocking API2020-10-23T07:06:28ZTomasz LemiechNetwork socket not set to nonblocking mode despite using nonblocking APIhttps://gitlab.xiph.org/xiph/icecast-libshout/commit/0ac7ed9e84c3871d4427acc1ce59dca5e4af21ef introduced a bug which causes network sockets not to be set into nonblocking mode when requested with `shout_set_nonblocking(s, 1)`. This can b...https://gitlab.xiph.org/xiph/icecast-libshout/commit/0ac7ed9e84c3871d4427acc1ce59dca5e4af21ef introduced a bug which causes network sockets not to be set into nonblocking mode when requested with `shout_set_nonblocking(s, 1)`. This can be demonstrated simply by tracing an example `nonblocking` app.
Bad (current master HEAD):
```
$ strace -f -e fcntl,fcntl64,socket,connect ./nonblocking
(...)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
```
Good (v2.4.3):
```
(...)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now i n progress)
```
In the first case `fcntl` is never called and the socket stays in the default (blocking) mode.
This is due to the following condition in `shout_connection_connect`:
```C
if (con->nonblocking == SHOUT_BLOCKING_DEFAULT)
shout_connection_set_nonblocking(con, shout_get_nonblocking(shout));
```
But as `con->nonblocking` is never initialized to this value, it's effectively `if(0)`.
Adding a simple:
```C
con->nonblocking = SHOUT_BLOCKING_DEFAULT;
```
to `shout_connection_new` fixes the problem. But this turns the above condition into `if(1)`, so is it really needed? It was not there before. What's the idea behind this?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2381Multimedia signing key expired for openSUSE OBS Multimedia2022-04-12T14:00:12ZTom ZetMultimedia signing key expired for openSUSE OBS MultimediaThe Multimedia signing key as written in here [wiki.xiph.org](https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop) expired 2020-01-30.The Multimedia signing key as written in here [wiki.xiph.org](https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop) expired 2020-01-30.Thomas B. RückerThomas B. Rücker