Icecast-IceS issueshttps://gitlab.xiph.org/xiph/icecast-ices/-/issues2019-04-19T11:32:52Zhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/735Setting reconnectattempts to 0 causes ices to loop indefinitely.2019-04-19T11:32:52ZGitlab BotSetting reconnectattempts to 0 causes ices to loop indefinitely.Setting <reconnectattempts> to 0 causes ices to loop indefinitely:
```
[2005-11-08 20:46:11] EROR stream/ices_instance_stream Send error: Socket error (Broken pipe)
[2005-11-08 20:46:11] DBUG input/input_flush_queue Input queue flush r...Setting <reconnectattempts> to 0 causes ices to loop indefinitely:
```
[2005-11-08 20:46:11] EROR stream/ices_instance_stream Send error: Socket error (Broken pipe)
[2005-11-08 20:46:11] DBUG input/input_flush_queue Input queue flush requested
[2005-11-08 20:46:11] EROR stream/ices_instance_stream Send error: Socket error (Broken pipe)
[2005-11-08 20:46:11] DBUG input/input_flush_queue Input queue flush requested
[2005-11-08 20:46:11] EROR stream/ices_instance_stream Send error: Socket error (Broken pipe)
[2005-11-08 20:46:11] DBUG input/input_flush_queue Input queue flush requested
[2005-11-08 20:46:11] EROR stream/ices_instance_stream Send error: Socket error (Broken pipe)
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/621File descriptor leak. Ices 0.4.2019-04-19T11:32:52ZsimengFile descriptor leak. Ices 0.4.When ices-0.4 is compiled with HAVE_LIBFAAD there is a leak when files are not handled by FAAD.
```
diff -ru ices-0.4-orig/src/in_mp4.c ices-0.4/src/in_mp4.c
--- ices-0.4-orig/src/in_mp4.c Sat Jul 31 04:35:29 2004
+++ ices-0.4/src/in_...When ices-0.4 is compiled with HAVE_LIBFAAD there is a leak when files are not handled by FAAD.
```
diff -ru ices-0.4-orig/src/in_mp4.c ices-0.4/src/in_mp4.c
--- ices-0.4-orig/src/in_mp4.c Sat Jul 31 04:35:29 2004
+++ ices-0.4/src/in_mp4.c Sun Feb 27 02:38:41 2005
@@ -68,8 +68,10 @@
if (! self->filesize)
return 1;
- if ((mp4file = MP4Read(self->path, 0)) == MP4_INVALID_FILE_HANDLE)
+ if ((mp4file = MP4Read(self->path, 0)) == MP4_INVALID_FILE_HANDLE) {
+ MP4Close(mp4file);
return 1;
+ }
/* find audio stream */
track = MP4_INVALID_TRACK_ID;
```Brendan Cully Brendan Cully https://gitlab.xiph.org/xiph/icecast-ices/-/issues/617ices0 fails when using USR1 signal to bump it from final track in playlist2019-04-19T11:32:52Zdanstowellices0 fails when using USR1 signal to bump it from final track in playlistHi - I use ices0 to pipe MP3 to icecast (on Mac OS X), and I often use a "USR1" signal to nudge ices0 on to the next track in our static playlist (to keep it to a desired synchronisation pattern). My typical command is
sudo kill -USR1 ...Hi - I use ices0 to pipe MP3 to icecast (on Mac OS X), and I often use a "USR1" signal to nudge ices0 on to the next track in our static playlist (to keep it to a desired synchronisation pattern). My typical command is
sudo kill -USR1 `cat /path/to/ices.pid`
If you do this while ices0 is playing the _very last entry_ in a static playlist, it seems to choke - ices stops playing altogether.
I'd be grateful for a fix to this, because it would mean I could automate this nudging. At present I can't in case it stops the stream :)
Thanks - [Dan](http://www.mcld.co.uk/)Brendan Cully Brendan Cully https://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 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/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/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/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/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/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/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/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/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/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/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 Smith