Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2019-05-14T16:44:28Zhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2303libshout's state machine should be rewritten2019-05-14T16:44:28ZPhilipp Schafftlibshout's state machine should be rewrittenThe current state machine was designed without "modern" extensions (such as TLS and PUT) already around. For those extensions and modes it does not support full support and is error-prone.
Therefore the state machine should be rewritte...The current state machine was designed without "modern" extensions (such as TLS and PUT) already around. For those extensions and modes it does not support full support and is error-prone.
Therefore the state machine should be rewritten.
See also: #2301, #2153, and #2298.Philipp SchafftPhilipp Schafft2018-12-12https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2298building with TLS causes shout_set_metadata to fail with SHOUTERR_INSANE with...2019-05-14T16:44:28ZRJ Ryanbuilding with TLS causes shout_set_metadata to fail with SHOUTERR_INSANE with Shoutcast serversRelated to #2244 -- tested with latest libshout master (2dd6cfb7190bdfd4cb5a1fb663f00e630462e9e1) on OSX.
Mixxx 2.0 and onwards uses libshout 2.4.1 built with TLS enabled (using SHOUT_TLS_AUTO) on OSX and we were receiving user reports ...Related to #2244 -- tested with latest libshout master (2dd6cfb7190bdfd4cb5a1fb663f00e630462e9e1) on OSX.
Mixxx 2.0 and onwards uses libshout 2.4.1 built with TLS enabled (using SHOUT_TLS_AUTO) on OSX and we were receiving user reports of metadata not working with Shoutcast (not Icecast) servers.
I saw ph3-der-loewe's patch:
https://github.com/xiph/Icecast-libshout/commit/4542dc2d7efd7b12ab80a45cfa4bb4ff6d03fc24
which I thought would fix it, but I can still reproduce at head.
I dug in and realized that shout_set_metadata was returning SHOUTERR_INSANE because self->tls_mode_used is SHOUTERR_NOTLS at the time we send metadata. My understanding is that if tls_mode is SHOUT_TLS_AUTO, then the correct result of the state machine is that self->tls_mode_used becomes SHOUT_TLS_DISABLED if a TLS upgrade is not possible.
Here is the Mixxx bug which has more details:
https://bugs.launchpad.net/mixxx/+bug/1544739
I applied this hack to try_connect where it says "TODO: do something":
```
++ if (self->tls_mode == SHOUT_TLS_AUTO_NO_PLAIN) {
++ self->tls_mode_used = SHOUTERR_NOTLS;
++ return SHOUTERR_NOTLS;
++ }
++ self->tls_mode_used = SHOUT_TLS_DISABLED;
```
which works around the issue.
I doubt this is the right fix though since I think this block is supposed to "poke the server" like the comment says above :) since we haven't successfully probed the server yet.
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2244Libshout fails to handle auto TLS properly2019-05-14T16:44:28ZStephen FairchildLibshout fails to handle auto TLS properlyIf I connect using auto TLS and the server does not support it then we will connect but the TLS mode will still be set to auto. This prevents shout_set_metadata from working. Worse still, it will connect when the no plaintext option is s...If I connect using auto TLS and the server does not support it then we will connect but the TLS mode will still be set to auto. This prevents shout_set_metadata from working. Worse still, it will connect when the no plaintext option is selected.
Patch supplied.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2364https stream play 1 second and stop2019-05-13T11:56:47ZMichelhttps stream play 1 second and stopWe have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bul...We have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bult a new RPM for Icecast 2.4.4 on the last version of CentOS Linux release 7.6.1810 (Core) include the openssl update. (OpenSSL 1.0.2k-fips 26 Jan 2017)
I run it on the debug mode (4). Tonight i have the same problem on https on mount /live a mp3 192k stream. It play 2 seconds and stop. (when i try to use include .m3u so https.../live.m3u he go to http in the software player)
Here is the debug error log. I hope you find them useful (see /live) :
```
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52301)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (16)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52302)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_read (18373627904)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_sent (82768157916)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50480)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (1)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (12)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listener_connections (11687)
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source max on /live is 400 (cur 0)
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source Added client to /live
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (11)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (0)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50481)
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
```
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2309Can't connect to Icecast server from multiple tabs in Firefox2019-05-13T11:49:02ZugultopuCan't connect to Icecast server from multiple tabs in Firefox
## Steps to Reproduce
1. Open Firefox 50.1.0.
2. Connect to an Icecast mount point. The stream will start.
3. Open a new tab and try to connect to the same mount point. The connection won't be established.
4. Open a Private Window and t...
## Steps to Reproduce
1. Open Firefox 50.1.0.
2. Connect to an Icecast mount point. The stream will start.
3. Open a new tab and try to connect to the same mount point. The connection won't be established.
4. Open a Private Window and try to connect to the same mount point. The stream will start.
5. Open another tab in the Private Window and try to connect to the same mount point. The connection won't be established.
## Actual Results
Can't establish connection to an Icecast server from multiple tabs in Firefox.
## Expected Results
Establish connection to an Icecast server from multiple tabs in Firefox.
## Notes
1. The issue does not occur on Chrome. It is possible to connect to a mount point from as many tabs as you like.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2318icecast fails to build against openssl-1.1 that lacks deprecated features2019-04-24T17:23:49ZGitlab Boticecast fails to build against openssl-1.1 that lacks deprecated featuresicecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
`...icecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
```
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I./common/ -Wall -ffast-math -fsigned-char -I/usr/include/libxml2 -I/usr/include -pthread -march=native -O2 -pipe -c -o connection.o connection.c
connection.c: In function ‘get_ssl_certificate’:
connection.c:195:5: warning: implicit declaration of function ‘SSL_load_error_strings’ [-Wimplicit-function-declaration]
SSL_load_error_strings(); /* readable error messages */
^
connection.c:196:5: warning: implicit declaration of function ‘SSL_library_init’ [-Wimplicit-function-declaration]
SSL_library_init(); /* initialize library */
^
connection.c:198:12: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
method = SSLv23_server_method();
^
```
And later in the linking part:
```
libtool: link: i686-pc-linux-gnu-gcc -pthread -march=native -O2 -pipe -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -o icecast cfgfile.o main.o logging.o sighandler.o connection.o global.o util.o slave.o source.o stats.o refbuf.o client.o xslt.o fserve.o admin.o md5.o format.o format_ogg.o format_mp3.o format_midi.o format_flac.o format_ebml.o format_kate.o format_skeleton.o format_opus.o event.o event_log.o event_exec.o acl.o auth.o auth_htpasswd.o auth_anonymous.o auth_static.o format_vorbis.o format_theora.o format_speex.o auth_url.o event_url.o yp.o -L/usr/lib -Wl,--as-needed common/net/.libs/libicenet.a common/thread/.libs/libicethread.a common/httpp/.libs/libicehttpp.a common/log/.libs/libicelog.a common/avl/.libs/libiceavl.a common/timing/.libs/libicetiming.a -lcurl -lnghttp2 -lidn2 -lssl -lcrypto -lspeex -ltheora -lvorbis -logg -lxslt -lxml2 -lz -ldl -lm -pthread
connection.o: In function `connection_accept_loop':
connection.c:(.text+0x736): undefined reference to `SSL_load_error_strings'
connection.c:(.text+0x73b): undefined reference to `SSL_library_init'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:512: icecast] Error 1
```
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2358Improve Icecast's logging of developer only messages2019-04-23T13:54:32ZPhilipp SchafftImprove Icecast's logging of developer only messagesCurrently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log ...Currently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log level or log flag (as those messages may themself have different log levels as per their logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2348Auth backend for enforcing initial 4012019-04-23T13:54:32ZPhilipp SchafftAuth backend for enforcing initial 401There should be an auth backend that enforces an initial 401 reply.
This would be useful to off-load generation of those initial replies from other backends such as the URL auth backend.
This works by:
```
If (!user || !password) {
...There should be an auth backend that enforces an initial 401 reply.
This would be useful to off-load generation of those initial replies from other backends such as the URL auth backend.
This works by:
```
If (!user || !password) {
return failed;
} else {
return no match;
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/75Ices shuts down if there is an empty line at the beginning of a playlist2019-04-19T11:33:11ZManuel LoraIces shuts down if there is an empty line at the beginning of a playlist```
Ices (2) shuts down if there is an empty line at the beginning of a playlist
when connecting to icecast(2). CVS.
This also happens if there is a space between songs.
[2001-11-07 00:13:05] INFO ices-core/main ices started...
[2001...```
Ices (2) shuts down if there is an empty line at the beginning of a playlist
when connecting to icecast(2). CVS.
This also happens if there is a space between songs.
[2001-11-07 00:13:05] INFO ices-core/main ices started...
[2001-11-07 00:13:05] INFO stream/ices_instance_stream Connected to server:
127.0.0.1:8001/test.ogg
[2001-11-07 00:13:05] INFO playlist-builtin/playlist_read No more filenames
available, end of playlist[2001-11-07 00:13:05] DBUG
stream-shared/stream_wait_for_data Shutdown signalled: thread shutting
down[2001-11-07 00:13:05] DBUG encode/encode_clear Clearing encoder engine
[2001-11-07 00:13:06] DBUG input/input_loop An instance died, removing it
[2001-11-07 00:13:06] DBUG input/input_flush_queue Input queue flush requested
[2001-11-07 00:13:06] DBUG input/input_loop All instances removed, shutting
down control thread.
[2001-11-07 00:13:06] INFO ices-core/main Shutdown complete
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/261read metadata on startup2019-04-19T11:32:53Zroberead metadata on startup```
it would be great if ices would read the metadata file on startup (not after
the first USR1 is received by the master process) if it's configured to parse
external metadata files at all.
``````
it would be great if ices would read the metadata file on startup (not after
the first USR1 is received by the master process) if it's configured to parse
external metadata files at all.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/276Ices leaks memory after losing connection(s) to icecast2019-04-19T11:32:53ZgshangIces leaks memory after losing connection(s) to icecast```
We run ices2 with three seperate streams - one unchanged, one a quality 0
circa 64kbps stream, and the other a quality -1 22khz mono stream. It
seems that when cron.daily runs, one or more of these streams will lose
connectivity wit...```
We run ices2 with three seperate streams - one unchanged, one a quality 0
circa 64kbps stream, and the other a quality -1 22khz mono stream. It
seems that when cron.daily runs, one or more of these streams will lose
connectivity with the icecast2 server (which is running on another box).
The number of streams dropped varies from day to day. After this point,
it appears that ices leaks memory until it eventually runs out of memory
and is killed by the kernel.
To illustrate this, here's a ps -aux from when ices was started yesterday
afternoon (US time):
kirk 8589 0.1 1.5 11376 3876 tty3 S 16:23 0:00 ../ices
egoplay.xml
kirk 8591 0.0 1.5 11376 3876 tty3 S 16:23 0:00 ../ices
egoplay.xml
kirk 8592 13.6 1.5 11376 3876 tty3 S 16:23 0:04 ../ices
egoplay.xml
kirk 8593 0.0 1.5 11376 3876 tty3 S 16:23 0:00 ../ices
egoplay.xml
kirk 8594 4.8 1.5 11376 3876 tty3 S 16:23 0:01 ../ices
egoplay.xml
These are pretty typical of what it looked like prior to the streams being
disconnected at 01:01 this morning. Here's what it looked like at about
03:42:
kirk 8589 0.0 69.2 185692 177352 ? S Oct31 0:01 ../ices
egoplay.xml
kirk 8591 0.0 69.2 185692 177352 ? S Oct31 0:00 ../ices
egoplay.xml
kirk 8592 16.8 69.2 185692 177352 ? R Oct31 114:23 ../ices
egoplay.xml
kirk 8593 6.1 69.2 185692 177352 ? R Oct31 41:58 ../ices
egoplay.xml
kirk 8594 9.6 69.2 185692 177352 ? R Oct31 65:16 ../ices
egoplay.xml
And here's what it looked like just before Kirk killed it off just before
6Am:
kirk 8589 0.0 80.1 320268 205368 ? S Oct31 0:03 ../ices
egoplay.xml
kirk 8591 0.0 80.1 320268 205368 ? S Oct31 0:00 ../ices
egoplay.xml
kirk 8592 18.3 80.1 320268 205368 ? R Oct31 149:13 ../ices
egoplay.xml
kirk 8593 9.4 80.1 320268 205368 ? R Oct31 76:49 ../ices
egoplay.xml
kirk 8594 12.3 80.1 320268 205368 ? R Oct31 100:08 ../ices
egoplay.xml
Left to its own devices, it would have run out of memory.
The logs don't say a lot. The ices log says nothing, really. The only
pointer that something's gone wrong is the fact that the encoder and
resample initialisations stop appearing in the log with each song. The
songs continue to be printed, however.
the icecast error log seems to indicate that the source just died at the
other end.
[2002-11-01 01:01:40] WARN source/source_main Disconnecting source:
socket timeout (10 s) expired
[2002-11-01 01:01:40] INFO source/source_main Removing source following
disconnection
[2002-11-01 01:01:40] DBUG source/source_main Source exiting
[2002-11-01 01:01:40] WARN source/source_main Disconnecting source:
socket timeout (10 s) expired
[2002-11-01 01:01:40] INFO source/source_main Removing source following
disconnection
[2002-11-01 01:01:40] DBUG source/source_main Source exiting
[2002-11-01 01:01:40] WARN source/source_main Disconnecting source:
socket timeout (10 s) expired
[2002-11-01 01:01:40] INFO source/source_main Removing source following
disconnection
[2002-11-01 01:01:40] DBUG source/source_main Source exiting
This has been happening consistantly since I first wrote about it on the
9th of October.
http://www.xiph.org/archives/icecast/3367.html
http://www.xiph.org/archives/icecast/3401.html
This is with current CVS ices and libshout2.
What I speculate is happening is that, for whatever reason, probably due
to system load with updatedb or sometihng, one or more streams lose their
connection with icecast. Despite the settings in the icex XML config, no
attempts are made to reconnect, acording to all of the logs. So some part
of ices seems to think that they're still connected.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/277resampling problems2019-04-19T11:32:53Zjstrawresampling problems```
ices seg faults every time we try to run it with resampling. Vakor suggested
that it is a config problem, so I am going to paste configs here.
we don't know if it is an ices or icecast problem, if this is the wrong place,
sorry, ple...```
ices seg faults every time we try to run it with resampling. Vakor suggested
that it is a config problem, so I am going to paste configs here.
we don't know if it is an ices or icecast problem, if this is the wrong place,
sorry, please put it where it should reside.
--ices resample--
<?xml version="1.0"?>
<ices>
<background>0</background> <!-- run in background? (unimplemented) -->
<logpath>/tmp</logpath> <!-- where logs, etc go. -->
<logfile>ices.log</logfile>
<loglevel>4</loglevel> <!-- 1=error,2=warn,3=info,4=debug -->
<consolelog>0</consolelog> <!-- logfile is ignored if this is set to 1 -->
<stream>
<metadata>
<name>Freenode Radio</name>
<genre>Various</genre>
<description></description>
</metadata>
<input>
<module>oss</module>
<param name="rate">44100</param> <!-- samplerate -->
<param name="channels">2</param> <!-- number of channels -->
<param name="device">/dev/dsp</param> <!-- audio device -->
<param name="metadata">1</param>
</input>
<instance>
<hostname>marconi.wopn.org</hostname>
<port>*****</port>
<password>*************</password>
<mount>/wopn-verylowbitrate.ogg</mount>
<encode>
<quality>-1</quality>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<downmix>1</downmix>
<resample>
<in-rate>44100</in-rate>
<out-rate>11025</out-rate>
</resample>
</instance>
<instance>
<hostname>marconi.wopn.org</hostname>
<port>*****</port>
<password>************</password>
<mount>/wopn-modem.ogg</mount>
<encode>
<quality>-1</quality>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<downmix>1</downmix>
<resample>
<in-rate>44100</in-rate>
<out-rate>22050</out-rate>
</resample>
</instance>
<instance>
<hostname>marconi.wopn.org</hostname>
<port>*****</port>
<password>*****************</password>
<mount>/wopn-broadband.ogg</mount>
<encode>
<quality>2</quality>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<downmix>0</downmix>
</instance>
</stream>
</ices>
-- icecast config --
<icecast>
<location>Freenode Radio</location>
<admin>staff@wopn.org</admin>
<limits>
<clients>50</clients>
<sources>4</sources>
<threadpool>5</threadpool>
<client-timeout>60</client-timeout>
<header-timeout>30</header-timeout>
<source-timeout>30</source-timeout>
</limits>
<source-password>****</source-password>
<relay-password>****</relay-password>
<directory>
<touch-freq>5</touch-freq>
<server>
<host>yp.icecast.org</host>
<touch-freq>15</touch-freq>
</server>
</directory>
<hostname>marconi.wopn.org</hostname>
<port>*****</port>
<!--<bind-address>127.0.0.1</bind-address>-->
<!--<master-server>127.0.0.1</master-server>-->
<!--<master-server-port>8001</master-server-port>-->
<!--<master-update-interval>120</master-update-interval>-->
<!--<master-password>hackme</master-password>-->
<fileserve>1</fileserve>
<paths>
<basedir>/home/wopn</basedir>
<logdir>/home/wopn/icecast_logs</logdir>
<webroot>/home/wopn/public_html</webroot>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
</logging>
<security>
<chroot>0</chroot>
<!-- <changeowner>
<user>nobody</user>
<group>nogroup</group>
</changeowner> -->
</security>
</icecast>
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/278reencodes mono files as DOUBLY FAST stereo2019-04-19T11:32:53Zdoctorkaedingreencodes mono files as DOUBLY FAST stereo```
This is probably a libvorbis bug, since it shows up in gnometoaster, too.
Ices reencodes mono ogg files as DOUBLE-SPEED mp3s. Sounds terrible.
``````
This is probably a libvorbis bug, since it shows up in gnometoaster, too.
Ices reencodes mono ogg files as DOUBLE-SPEED mp3s. Sounds terrible.
```Brendan Cully Brendan Cully https://gitlab.xiph.org/xiph/icecast-ices/-/issues/281A patch for an alsa input module2019-04-19T11:32:53ZjchuA patch for an alsa input module```
``````
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/312build failure on solaris2019-04-19T11:32:53ZGitlab Botbuild failure on solaris```
has been reported serveral times already. Later solaris versions don't come with
inet_aton and instead require inet_pton instead. A simple fix is to add a define in
sock.h like
#define inet_aton(a,b) inet_pton(AF_INET, (a),...```
has been reported serveral times already. Later solaris versions don't come with
inet_aton and instead require inet_pton instead. A simple fix is to add a define in
sock.h like
#define inet_aton(a,b) inet_pton(AF_INET, (a), (b))
protected by a #ifdef for solaris or better still HAVE_INET_ATON from configure.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/315[PATCH] python playlist handler for ices22019-04-19T11:32:53Zsherpya[PATCH] python playlist handler for ices2```
I've ported playlist python to ices 2,
download changed files here: http://oss.netfarm.it/download/playlist_python.tar.gz
* It works in threaded/not thread mode, metadata updating not supported by core
* Need to be fixed sigint han...```
I've ported playlist python to ices 2,
download changed files here: http://oss.netfarm.it/download/playlist_python.tar.gz
* It works in threaded/not thread mode, metadata updating not supported by core
* Need to be fixed sigint handling, since sigint kill this cruft
* before calling pl->clear, for now I've hacked to intercept sig int
* but doesn't work when ices kill the module after too many errors detected
I've added the proto of the init function into playlist_basic.h, maybe not the
right place, to compile you need to add the right compile options to configure
script/makefile.
I've also noticed sigint message is not dispatched correctly to child thread (or
I've not found how it works...) since without installing a sigint handler into
playlist python, the thread will die with segfault because it cannot
uninitialize python enviroment.
I never made perl module but I think it would be easy to port also perl handler.
I need to fix first sigint issues...
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/499Statistics relay2019-04-19T11:32:53ZjhillmanStatistics relay```
When streams are being sent to the server from more than one ip address, the
statistics relay stops working for all streams on the server. Example:
Starting with a freshly rebooted server... have "Bob" on ip adress "X" start a
st...```
When streams are being sent to the server from more than one ip address, the
statistics relay stops working for all streams on the server. Example:
Starting with a freshly rebooted server... have "Bob" on ip adress "X" start a
stream with the mountpoint /bob and have him start gathering listener stats on
that mountpoint... (all is fine at this point) Now have bill on ip
address "Y" start a stream with the mountpoint /bill. Regardless of what you
do next, no one can pull listener stats any more. In short you can have as
many streams running as you want to al long as they all come from the same ip
address, if someone starts a stream from a second ip address the stats for all
streams are killed. The server is running on Windows XP Pro and the streams
are comming from Sam2 and Simplecast. We tried both using Sam2. We tried both
using Simplecast. We tried using one of each. I also tried using both Sam2
and simplecast on the same system at one time. As long as there was only one
ip address sending streams to Icecast2 there was never a problem. As soon as
we added a stream from a second IP address, the listener stats crash.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/510metadata truncated at high ascii chars2019-04-19T11:32:52ZThomasmetadata truncated at high ascii chars```
Metadata containing high ascii chars (> 127) such german umlaute (ü ä ö) is not
sent to the icecast server correctly. The metadata-entry is truncated at the
position of the first special char.
For example "Soylent Grün" becomes "S...```
Metadata containing high ascii chars (> 127) such german umlaute (ü ä ö) is not
sent to the icecast server correctly. The metadata-entry is truncated at the
position of the first special char.
For example "Soylent Grün" becomes "Soylent Gr", "L'amé Immortelle"
becomes "L'am".
I saw this effect in ices2-beta4.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/594ices return value of 1 on successful startup2019-04-19T11:32:52ZGitlab Botices return value of 1 on successful startupint main in ices.c says it will end in ices_setup_shutdown by calling exit(0), however this
actually calls exit(1) <setup.c, line136>. This causes startup scripts that use the daemon
command within fedora core 1,2,3 and redhat 9 to rep...int main in ices.c says it will end in ices_setup_shutdown by calling exit(0), however this
actually calls exit(1) <setup.c, line136>. This causes startup scripts that use the daemon
command within fedora core 1,2,3 and redhat 9 to report a failure starting ices. I know it is
trivial, but it is very annoying in ices-0.4Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/598ices segfaults upon reading the config.xml2019-04-19T11:32:52Zjnagyjrices segfaults upon reading the config.xml```
jnagyjr@joseph-a-nagy-jr ~/ices $ gdb ices
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it u...```
jnagyjr@joseph-a-nagy-jr ~/ices $ gdb ices
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run config.xml
Starting program: /usr/bin/ices config.xml
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 12561)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 12561)]
0x00000000 in ?? ()
(gdb) stop
(gdb) quit
The program is running. Exit anyway? (y or n) y
jnagyjr@joseph-a-nagy-jr ~/ices $ ices config.xml
Segmentation fault
```Michael SmithMichael Smith