Icecast Streaming Media Server

[Oele]

And here's what i think is one of those "trigger cases". It stopped with a "Aborted (core dumped)".


gdb:
------------------------------------------------------------------------------------------------------------
(gdb) thread apply all bt

Thread 7 (process 5879):
#0 0xb7713410 in __kernel_vsyscall ()
#1 0xb7112cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2 0x0807230c in thread_sleep (len=3219768732) at thread.c:620
#3 0x08055ed2 in slave_initialize () at slave.c:1118
#4 0x0804f0c3 in main (argc=0, argv=0x374bba61) at main.c:223

Thread 6 (process 5880):
#0 0xb7713410 in __kernel_vsyscall ()
#1 0xb7155118 in send () from /lib/tls/i686/cmov/libc.so.6
#2 0x08070e69 in sock_write_bytes (sock=43, buff=0xb673bb68, len=3063535912) at sock.c:362
#3 0x08052168 in connection_send (con=0x80e4800, buf=0xb673bb68, len=3063535912) at connection.c:330
#4 0x0805ccc1 in client_send_bytes (client=0x80e47e8, buf=0xb673bb68, len=3063535912) at client.c:277
#5 0x080653f8 in write_buf_to_client (client=0x80e47e8) at format_ogg.c:521
#6 0x080595a0 in send_to_listener (client=0x80e47e8) at source.c:945
#7 0x0805d1a9 in worker (arg=0x8090e90) at client.c:420
#8 0x08072cd9 in _start_routine (arg=0x8090f40) at thread.c:660
#9 0xb706a4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#10 0xb7153e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 5 (process 5881):
#0 0xb7713410 in __kernel_vsyscall ()
#1 0xb7071626 in __lll_timedlock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb706d99f in _L_timedlock_129 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb706d204 in pthread_mutex_timedlock () from /lib/tls/i686/cmov/libpthread.so.0
#4 0x08071e6d in _mutex_lock_c (mutex=0x8090e98, file=0x8079d26 "client.c", line=372) at thread.c:732
#5 0x0805d360 in client_add_worker (client=0x80ea7b0) at client.c:372
#6 0x08051a4c in connection_thread (arg=0x0) at connection.c:970
#7 0x08072cd9 in _start_routine (arg=0x80910f8) at thread.c:660
#8 0xb706a4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#9 0xb7153e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 4 (process 21027):
#0 0xb7713410 in __kernel_vsyscall ()
#1 0xb7071626 in __lll_timedlock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb706d99f in _L_timedlock_129 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb706d204 in pthread_mutex_timedlock () from /lib/tls/i686/cmov/libpthread.so.0
#4 0x08071e6d in _mutex_lock_c (mutex=0x8090e98, file=0x80784c0 "slave.c", line=398) at thread.c:732
#5 0x08054515 in open_relay (relay=0x80a2590) at slave.c:398
#6 0x08054ed1 in start_relay_stream (arg=0x80abe58) at slave.c:536
#7 0x08072cd9 in _start_routine (arg=0xb69bb500) at thread.c:660
#8 0xb706a4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#9 0xb7153e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 3 (process 21050):
#0 0xb7713410 in __kernel_vsyscall ()
#1 0xb7149c07 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0x08053712 in util_timed_wait_for_fd (fd=40, timeout=15000) at util.c:83
#3 0x08053757 in util_read_header (sock=40, buff=0xb6db32b8 "", len=4096, entire=1) at util.c:119
#4 0x080544b2 in open_relay (relay=0x80a1ea0) at slave.c:326
#5 0x08054ed1 in start_relay_stream (arg=0x80ad0f8) at slave.c:536
#6 0x08072cd9 in _start_routine (arg=0xb6cca118) at thread.c:660
#7 0xb706a4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8 0xb7153e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (process 21063):
#0 0xb7713410 in __kernel_vsyscall ()
---Type <return> to continue, or q <return> to quit---
#1 0xb7149c07 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0x08053712 in util_timed_wait_for_fd (fd=7, timeout=15000) at util.c:83
#3 0x08053757 in util_read_header (sock=7, buff=0xb6afc2b8 "", len=4096, entire=1) at util.c:119
#4 0x080544b2 in open_relay (relay=0x80a36e8) at slave.c:326
#5 0x08054ed1 in start_relay_stream (arg=0x80a8748) at slave.c:536
#6 0x08072cd9 in _start_routine (arg=0xb682db30) at thread.c:660
#7 0xb706a4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8 0xb7153e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (process 21071):
#0 0xb7713410 in __kernel_vsyscall ()
#1 0xb70a8085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb70a9a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x08071f27 in _mutex_lock_c (mutex=0x8090e98, file=<value optimized out>, line=521) at thread.c:741
#4 0x08054ceb in start_relay_stream (arg=0x80ac210) at slave.c:521
#5 0x08072cd9 in _start_routine (arg=0xb636fde0) at thread.c:660
#6 0xb706a4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb7153e5e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)
------------------------------------------------------------------------------------------------------------


error.log:
------------------------------------------------------------------------------------------------------------
[2010-05-12 18:41:01] DBUG stats/modify_node_event update "global" outgoing_kbitrate (3391)
[2010-05-12 18:41:02] DBUG stats/modify_node_event update "global" outgoing_kbitrate (2419)
[2010-05-12 18:41:03] DBUG stats/modify_node_event update "global" outgoing_kbitrate (1880)
[2010-05-12 18:41:04] DBUG stats/modify_node_event update "global" outgoing_kbitrate (1537)
[2010-05-12 18:41:05] DBUG stats/modify_node_event update "global" outgoing_kbitrate (1300)
[2010-05-12 18:41:05] INFO slave/get_relay_response Header read failure
[2010-05-12 18:41:06] DBUG stats/modify_node_event update "global" outgoing_kbitrate (1127)
[2010-05-12 18:41:06] EROR thread/mutex lock error triggered at slave.c:521 (110)
------------------------------------------------------------------------------------------------------------

[JohnnyOh]

Hi,

I installed a icecast 2.3.2-kh23 on a testing maschine.
This icecast should relay a stream from a 2.3.2-kh22g icecast.
Unfortunately I am not able to play the stream. There is a connection, but ist "timed out"

This is my relay-config:

<relay>
<server>192.168.10.66</server>
<port>80</port>
<mount>/test.mp3</mount>^M
<local-mount>/localtest.mp3</local-mount>^M
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>^M
</relay>

Do I have to change anything on relay settings to get it work?
I would like to change to the kh23-version because of the fixed fallback-mountpoint issue.

Kind regards

Johnny

[karlH]

The time out may be an issue with the sending end, it would depend on what is being done. I've have been flushing out some other issues. Oele did raise some cases that have been around a while and I think those look to be resolved now. The mpeg resync code seems to be stabilized now, which seems to be the issue that some have found when a stream is apparently active and content is being read but no data was sent to listeners.

karl.

[JohnnyOh]

Hi Karl,

thank you for your reply. Does it mean that you have released a new version?

Where can I download it for testing?

[karlH]

the latest code, which I think is more or less ready is at
www.icecast.pwp.blueyonder.co.uk/flv

karl.

[karlH]

ok, time for kh24. This includes the fixes for issues that have been raised with me, thanks to various people for help in tracking the bugs down. As a bonus, you can now use flash to get your mp3/aac streams without memory leaking, by requesting the stream with ?type=.flv appended to the mountpoint, icecast will now wrap the content in flv and magically prevent flash from leaking memory all over the place (until the next version at least).

Note the new website, my ISP dropped the older domain without telling me so if you get a 403 response then that is why.

karl.

[m3gab0y]

Please, upload your old releases, because I can't download any of them, and the new ones are unusable for production mode.

[karlH]

how old a release? I've had one report on kh24 which seems to be an odd case and I have a fix for that (waiting on confirmation). I've no other issues reported to me on that.

karl.

[m3gab0y]

Since kh17 it's not good for a production use, as it crashes sometimes, due to various verid reasons. As for now when I run kh24 I get the error screen for Windows, and on Linux the title updates (not always working) and the connection dropouts at randon for both source and clients is still there.

[karlH]

Can you send me more specifics on the setup you are running which experiences that. The xml and logs will be a starting point in identifying the cause of any issues that arise.

karl.

[m3gab0y]

Here is some info of the testing server:

http://m3gab0y.com:8000/

Windows XP SP3, 32 Bit
Plenty of bandwidth (gigabit network)
Running Icecast kh24

Config:

[humanclay]

I just upgraded from KH21a to KH24 and noticed the following:

[2010-06-14 21:03:29] INFO slave/relay_read relay /mount-64k.ogg terminated quickly, will restart in 60s
[2010-06-14 21:03:29] INFO source/source_shutdown Source "/mount-64k.ogg" exiting
[2010-06-14 21:03:29] INFO slave/relay_read standing by to restart relay on /mount-64k.ogg



[2010-06-14 21:04:29] INFO slave/relay_startup Detected listeners on relay /mount-64k.ogg
[2010-06-14 21:04:29] INFO slave/start_relay_stream Starting relayed source at mountpoint "/mount-64k.ogg"


When I went to connect to the stream it took just under 60 seconds for the player to begin playing audio, corresponding to the delay in the log above for relaying the stream. Is there any way to shorten this interval?

[humanclay]

It looks like the 60 second wait corresponds to this part of the code in slave.c


if (client->worker->current_time.tv_sec - client->connection.con_time < 300)
{
INFO1 ("relay %s terminated quickly, will restart in 60s", relay->localmount);
relay->start = client->worker->current_time.tv_sec + 60;
}


What is the motivation for this? Is 300 an appropriate value? Why 60 seconds? That seems like a really long wait time.

[karlH]

It's really to stop the relay from being stop/started repeatedly. The idea is to break that possible loop if the stream hasn't been running for at least 5 mins, the case it's trapping for is a stream that exists but dies after a short time. You may be experiencing it because it looks like an on-demand relay and the relay will shut off when listeners drops to zero. The 60 seconds was just a number I thought would be a sensible interval but I'm not fixed on that.

karl

[humanclay]

It seems to me that 5 or 10 seconds would be a more reasonable value. Maybe it should be a setting in the XML?