Icecast-IceS issueshttps://gitlab.xiph.org/xiph/icecast-ices/-/issues2019-04-19T11:33:11Zhttps://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 Smithhttps://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/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/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/742stack-smashing crash with ices2 (or libshout)2019-04-19T11:32:52Zgtgbrstack-smashing crash with ices2 (or libshout)Hi,
another ices2 crash to report. This is ices-2.0.1 and libshout-2.1 on OpenBSD 3.8-stable/i386. The former has the patch for the re-fixed (ticket 720) applied.
Even though it seems to crash while being on the way to shut down anyway...Hi,
another ices2 crash to report. This is ices-2.0.1 and libshout-2.1 on OpenBSD 3.8-stable/i386. The former has the patch for the re-fixed (ticket 720) applied.
Even though it seems to crash while being on the way to shut down anyways, it might also be interesting to find out why it does that in the first place. Two other ices2 instances keep on streaming fine ... which also means that the computer (Athlon TB 1GHz) is rather busy anyways -- the cause could be related to being temporarily out of resources (CPU or I/O).
The stack is clobbered, making the backtrace on the (unfortunately unthreaded) coredump rather useless:
```
Program terminated with signal 6, Aborted.
#0 0x03eab559 in kill () from /usr/lib/libc.so.38.2
#1 0x03ee7463 in abort () from /usr/lib/libc.so.38.2
#2 0x03ecaf12 in recvmsg () from /usr/lib/libc.so.38.2
#3 0x4e524157 in ?? ()
#4 0x72747320 in ?? ()
#5 0x2f6d6165 in ?? ()
#6 0x73656369 in ?? ()
#7 0x736e695f in ?? ()
#8 0x636e6174 in ?? ()
#9 0x74735f65 in ?? ()
#10 0x6d616572 in ?? ()
#11 0x00000000 in ?? ()
#12 0x000003fc in ?? ()
#13 0x7e2a3db8 in ?? ()
#14 0x23e7bab9 in _C_tolower_ () from /usr/lib/libc.so.38.2
#15 0x3c005ac0 in environ ()
#16 0x00000005 in ?? ()
#17 0x23e7a27e in _C_toupper_ () from /usr/lib/libc.so.38.2
#18 0x0000000b in ?? ()
#19 0x23e7bab9 in _C_tolower_ () from /usr/lib/libc.so.38.2
#20 0x00000008 in ?? ()
#21 0x23e7a20f in _C_toupper_ () from /usr/lib/libc.so.38.2
#22 0x00000016 in ?? ()
#23 0x8624d0b0 in ?? ()
#24 0x7e2a3e28 in ?? ()
#25 0x8624d800 in ?? ()
#26 0x23e80c04 in ?? () from /usr/lib/libc.so.38.2
#27 0x00000002 in ?? ()
#28 0x7f3d7700 in ?? ()
#29 0x7e2a3e28 in ?? ()
#30 0x03ecafbf in recvmsg () from /usr/lib/libc.so.38.2
#31 0x23e7a20f in _C_toupper_ () from /usr/lib/libc.so.38.2
#32 0x83421000 in ?? ()
#33 0x00000005 in ?? ()
#34 0x03ecaf22 in recvmsg () from /usr/lib/libc.so.38.2
#35 0x00000014 in ?? ()
#36 0x000003fc in ?? ()
#37 0x7e2a3e18 in ?? ()
#38 0x23e7a18c in _C_toupper_ () from /usr/lib/libc.so.38.2
#39 0x00000014 in ?? ()
#40 0x000003fc in ?? ()
#41 0x2a4d1b6c in _thread_sigstack () from /usr/lib/libpthread.so.6.1
#42 0x03ecb9b2 in recvmsg () from /usr/lib/libc.so.38.2
#43 0x00000000 in ?? ()
#44 0x8624d800 in ?? ()
#45 0x00000000 in ?? ()
#46 0x23e80c04 in ?? () from /usr/lib/libc.so.38.2
#47 0x00002000 in ?? ()
#48 0x000003fc in ?? ()
#49 0x7e2a3e88 in ?? ()
#50 0x23e80c04 in ?? () from /usr/lib/libc.so.38.2
#51 0x00000016 in ?? ()
#52 0x7f3d7700 in ?? ()
#53 0x7e2a3e68 in ?? ()
#54 0x03eccde3 in realloc () from /usr/lib/libc.so.38.2
Previous frame inner to this frame (corrupt stack?)
```
Ices2's logs show this:
```
[2005-11-16 20:03:02] EROR stream/ices_instance_stream Send error: Socket error (Broken pipe)
[2005-11-16 20:03:02] DBUG input/input_flush_queue Input queue flush requested
[2005-11-16 20:03:02] WARN stream/ices_instance_stream Trying reconnect after server socket error
[2005-11-16 20:03:02] INFO signals/signal_hup_handler Flushing logs
[2005-11-16 20:03:02] INFO playlist-builtin/event_handler Moving to next file in playlist.
[2005-11-16 20:03:02] INFO playlist-builtin/playlist_read Currently playing "/home/maxx/streams/schrabbel/Plaid_-_Rest_Proof_Clockwork_Bonus_Track.ogg"
[2005-11-16 20:03:03] EROR stream/ices_instance_stream Failed to reconnect to localhost:8000 (Socket error)
[2005-11-16 20:03:05] WARN stream/ices_instance_stream Trying reconnect after server socket error
[2005-11-16 20:03:05] EROR stream/ices_instance_stream Failed to reconnect to localhost:8000 (Socket error)
[2005-11-16 20:03:07] WARN stream/ices_instance_stream Trying reconnect after server socket error
[2005-11-16 20:03:07] EROR stream/ices_instance_stream Failed to reconnect to localhost:8000 (Socket error)
[2005-11-16 20:03:09] WARN stream/ices_instance_stream Trying reconnect after server socket error
[2005-11-16 20:03:09] EROR stream/ices_instance_stream Failed to reconnect to localhost:8000 (Socket error)
[2005-11-16 20:03:11] WARN stream/ices_instance_stream Trying reconnect after server socket error
[2005-11-16 20:03:11] EROR stream/ices_instance_stream Failed to reconnect to localhost:8000 (Socket error)
[2005-11-16 20:03:11] EROR stream/ices_instance_stream Reconnect failed too many times, giving up.
[2005-11-16 20:03:11] WARN stream/ices_instance_stream Too many errors, shutting down
```
During the crash, Icecast logged the following:
```
[2005-11-16 20:03:02] INFO connection/_handle_source_request Source logging in at mountpoint "/schrabbelator.ogg"
[2005-11-16 20:03:02] WARN connection/_handle_source_request Mountpoint /schrabbelator.ogg in use
[2005-11-16 20:03:12] WARN source/get_next_buffer Disconnecting source due to socket timeout
[2005-11-16 20:03:12] INFO source/source_shutdown Source "/schrabbelator.ogg" exiting
[2005-11-16 20:03:19] INFO source/source_main listener count on /kolaradio.ogg now 1
```
I'm willing to test patches, even those that simply add debugging messages for further testing -- _mx on FreeNode/#icecast.
Moritz
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/756ices0 (version 0.4) dont update tags after long time work2019-04-19T11:32:52ZGitlab Botices0 (version 0.4) dont update tags after long time workhi all
After long time work porgram ices0 (version 0.4), tags dont update and in log file:
Could not open cuefile [/usr/local/icecast/var/run/alternative/ices.cue] for writing, cuefile not updated!
After reboot program, all ok, but after...hi all
After long time work porgram ices0 (version 0.4), tags dont update and in log file:
Could not open cuefile [/usr/local/icecast/var/run/alternative/ices.cue] for writing, cuefile not updated!
After reboot program, all ok, but after long time this trable again
I used ices0 in screen and|or backgroundMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/907[ices] Feature request: Enable recoding for ogg files only2019-04-19T11:32:52Zeugene[ices] Feature request: Enable recoding for ogg files onlyI would like to see an ability to turn recoding on only for ogg files while letting mp3 files pass through without recoding at all.I would like to see an ability to turn recoding on only for ogg files while letting mp3 files pass through without recoding at all.Brendan Cully Brendan Cully https://gitlab.xiph.org/xiph/icecast-ices/-/issues/931[PATCH] improve ices2's playlist shuffler2019-04-19T11:32:52ZGitlab Bot[PATCH] improve ices2's playlist shufflerThe patch that I'll soon have attached below significantly improves ices2's shuffler randomness.
The quality of the PRNG is important to this new shuffler, which is why rand() is changed to the better-but-still-standard random(). To mak...The patch that I'll soon have attached below significantly improves ices2's shuffler randomness.
The quality of the PRNG is important to this new shuffler, which is why rand() is changed to the better-but-still-standard random(). To make this change consistent, rand() is changed to random() in src/encode.c as well (for the serial numbers.)
This implements the Knuth shuffle, AKA Fisher-Yates shuffle. Care has been taken to implement this subtle-and-quick-to-anger algorithm by testing it separately and making sure that it doesn't have any bias.
Works for me nicely over the course of several months now. If the PRNG were stronger, this should now have online-gambling quality. ;)
The additional LOG_DEBUG()s have proven useful, however, they are not necessary.
Achieving the same for ices-0.x would be trickier, iirc, and I personally am not too much interested in doing it.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/970ices-0.4 bug2017-11-05T22:14:59ZGitlab Botices-0.4 bugGood Day!
Thank your team for good products!
But however it is still more problems for usual (not advanced) users during icecast installation.
I have install icecast, but with ices-0.4 installation was the problem arose, which solution ...Good Day!
Thank your team for good products!
But however it is still more problems for usual (not advanced) users during icecast installation.
I have install icecast, but with ices-0.4 installation was the problem arose, which solution I could not find in the forums (I was find only the solutions for the developers or very advanced users).
This problem arose during work of "configure" command in the ice-0.4 Directory.
"...
checking whether stripping libraries is possible... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking shout/shout.h usability... yes
checking shout/shout.h presence... yes
checking for shout/shout.h... yes
checking for shout_new... no
configure: error: Could not find a usable libshout
[root@live-radio.intelkom.ru]#
"
I will be very grateful for help. Sorry for my poor English.Michael SmithMichael Smith