| View previous topic :: View next topic |
| Author |
Message |
ab-tools
Joined: 07 Sep 2010
Posts: 2
|
 Posted: Thu Sep 09, 2010 6:19 pm Post subject: |
 |
|
Hello Karl,
thank you very much for your fast reply!
That makes it much clearer to me.
Best regards
Andreas |
|
| Back to top |
|
 |
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Sun Sep 12, 2010 9:22 pm Post subject: |
|
|
kh27 is up. fixes only release, so recommended. A non-ogg metadata fix, possible race with worker wakeup and reducing contention on stats locking.
karl. |
|
| Back to top |
|
|
aoz1
Joined: 05 Sep 2010
Posts: 6
Location: UA
|
| Posted: Thu Sep 23, 2010 11:08 am Post subject: |
|
|
Karl,
It's look like one of firmware developers have some troubles when ts stream on beginning followed with the different speed.
Let's I do not dig in source. Does the settings
<burst-size>0</burst-size>
in you release completely switch off the burst on connect?
Thanks in advance.
Andrew. |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Thu Sep 23, 2010 12:10 pm Post subject: |
|
|
yes, for that sort of stream you probably want something fairly large, not the 64k typically used.
karl. |
|
| Back to top |
|
|
aoz1
Joined: 05 Sep 2010
Posts: 6
Location: UA
|
| Posted: Wed Oct 27, 2010 7:13 pm Post subject: |
|
|
Karl,
I just did not find good instruction how to catch segfault.
It was a good instruction in old Openser site, just for dummies like me 
Now just dissapeared.
So, I'll try:
for Centos, fedora, RH:
I start as user nobody with logging in /var/log/icecast:
| Code: |
#usermod -d /var/log/icecast nobody
|
in /etc/init.d/icecast:
| Code: |
start)
# Start daemon.
echo -n $"Starting icecast streaming daemon: "
ulimit -n 8192
ulimit -c unlimited
daemon "/usr/local/bin/icecast -b -c /usr/local/etc/icecast.xml > /dev/null"
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/icecast
;; |
Correct me pls, if I forgot something.
BTW, uptime was since Sept 24. Today morning (on offpeak time) down twice  |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Wed Oct 27, 2010 7:56 pm Post subject: |
|
|
Make sure you are on the latest work first as it may of been a fixed issue. you have the basics down but you may need a couple more things but lets be clear on what you need
make clean debug
rebuilds tree so that debugging works
ulimit -c unlimited
so the full core file can be written
If you run as changeowner then the OS is probably disabling the core dump for security reasons, under linux you can do
echo 2 > /proc/sys/fs/suid_dumpable
echo /tmp/core > /proc/sys/kernel/core_pattern
echo 1 > /proc/sys/kernel/core_uses_pid
karl. |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Fri Dec 03, 2010 4:16 pm Post subject: |
|
|
kh28 is up. Many thanks to the people providing feedback. A few cases that were causing corruption or stream playback problems are now fixed. This is mostly a bug fix release so is recommended.
The new features are the TS marker alignment (in 27.1), allows better handling of mpeg video streams, and the min-queue-size setting which defaults to burst-size.
burst-size has typically specified the smallest a queue can be for a stream but if min-queue-size is set larger than the burst then it allows for a listener to request more than what is normally burst. You can ask for more either via &burst=NNNNN or a header initial-burst:
karl. |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Fri Dec 03, 2010 4:22 pm Post subject: |
|
|
kh28 is up. Many thanks to the people providing feedback. A few cases that were causing corruption or stream playback problems are now fixed. This is mostly a bug fix release so is recommended.
The new features are the TS marker alignment (in 27.1), allows better handling of mpeg video streams, and the min-queue-size setting which defaults to burst-size.
burst-size has typically specified the smallest a queue can be for a stream but if min-queue-size is set larger than the burst then it allows for a listener to request more than what is normally burst. You can ask for more either via &burst=NNNNN or a header initial-burst:
Update. known issue with small burst size eg 0. most people won't see this as they have something like 64k (the default) but anything above 5k should avoid the problem.
karl. |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Tue Jan 25, 2011 2:48 am Post subject: |
|
|
Many thanks to those who provided feedback the last few weeks. About time to release a kh29 update. Lots of fixes all over really, a fair few stability updates in this so it is a recommended update. A number of relay restart issues and stalls have been resolved so if you experience stuck relays then that will be why. A few more details have been added to flv streams as well
karl. |
|
| Back to top |
|
|
Rrraymond
Joined: 04 Nov 2010
Posts: 11
|
| Posted: Thu Jan 27, 2011 8:41 am Post subject: |
|
|
Thanks a lot for this version!
Dumping OGG streams now work flawless!
Also, KH28 somehow crashed ShoutCast, which is functioning as a relay via streamTranscoderV3, that also is fixed! |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Thu Jan 27, 2011 1:55 pm Post subject: |
|
|
The kh28 tree did suffer in a few cases with corrupted incoming mp3/aac streams, that should be a lot tighter now. All I can say is that it wasn't a deliberate attempt to affect shoutcast
karl. |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Sat Jan 29, 2011 2:48 am Post subject: |
|
|
A win32 specific bug was reported which could appear as junk characters in metadata. This turns out to be down to a compiler issue and is now fixed in kh29.1. AFAIK no other platforms are affected like this. The build is available on the web site.
karl. |
|
| Back to top |
|
|
aoz1
Joined: 05 Sep 2010
Posts: 6
Location: UA
|
| Posted: Sat Feb 05, 2011 11:55 am Post subject: |
|
|
Karl,
backtrace on your e-mail.
regarding dump in Centos, fedora, RH,
if icecast or something else started using daemon function,
daemon overrite ulimit -c to 0
to make a dump on crash should be:
| Code: |
| DAEMON_COREFILE_LIMIT=unlimited daemon "/usr/local/bin/icecast -b -c /usr/local/etc/icecast.xml > /dev/null" |
|
|
| Back to top |
|
|
robertut
Joined: 31 Aug 2007
Posts: 156
|
| Posted: Tue Mar 29, 2011 1:18 pm Post subject: |
|
|
Dear Karl,
Have a look at this (listener number graph, pink area is total for all mounts, discrete lines are various mounts):
This appeared since we upgraded to version 2.3.2-kh29 (win32). It looks like drops affect all mounts. But it only happens during the day, when we have thousands of listeners.
On the web interface I see
| Quote: |
| server_start Tue, 29 Mar 2011 13:13:54 |
which seems to be similar with the latest drop on the graph.
I have these environment variables set, relating to IceCast:
ICE_LOCK_ABORT = 2
ICE_MUTEX_ABORT_old = 2 (I renamed it to "old" earlier, during a KH upgrade)
Config file is like this:
| Code: |
<?xml version="1.0" encoding="utf-8"?>
<icecast>
<limits>
<clients>15000</clients>
<sources>50</sources>
<queue-size>548576</queue-size>
<header-timeout>30</header-timeout>
<client-timeout>60</client-timeout>
<source-timeout>60</source-timeout>
<burst-size>137144</burst-size>
<max-bandwidth>800M</max-bandwidth>
<workers>8</workers>
</limits>
<authentication>
<source-password>pass</source-password>
<relay-password>pass</relay-password>
<admin-user>pass</admin-user>
<admin-password>pass</admin-password>
</authentication>
<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
</directory>
<hostname>my.host.name</hostname>
<master-update-interval>30</master-update-interval>
<listen-socket>
<bind-address>xx.xxx.xxx.xx</bind-address>
<port>80</port>
<so-sndbuf>32768</so-sndbuf>
</listen-socket>
<listen-socket>
<bind-address>xx.xxx.xxx.xy</bind-address>
<port>8080</port>
<so-sndbuf>32768</so-sndbuf>
</listen-socket>
<fileserve>1</fileserve>
<mime-types>C:\Program Files\Apache Software Foundation\Apache2.2\conf\mime.types</mime-types>
<paths>
<logdir>C:\Inetpub\ftproot\log\IceCast</logdir>
<webroot>C:\_IceCastSrv\web</webroot>
<adminroot>./admin</adminroot>
<alias source="/" dest="/statusz.xsl" />
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<playlistlog>playlist.log</playlistlog>
<loglevel>2</loglevel>
<!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
<logsize>100000</logsize>
<logarchive>1</logarchive>
</logging>
<relay>
<server>xx.xxx.xxx.xz</server>
<port>16000</port>
<mount>/rr.aac</mount>
<local-mount>/rr.aac</local-mount>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
<mount>
<mount-name>/rr.aac</mount-name>
<max-listeners>10000</max-listeners>
<max-listener-duration>43200</max-listener-duration>
<public>1</public>
<hidden>0</hidden>
<mp3-metadata-interval>8192</mp3-metadata-interval>
<type>audio/aacp</type>
<charset>ISO-8859-3</charset>
<stream-url>http://my.host.name2</stream-url>
<stream-name>rr</stream-name>
<stream-description>rr (aac+)</stream-description>
</mount>
</icecast> |
There are 22 such relay mounts. The relayed streams all come from the same master server, which is also Icecast, the same version as this.
In Windows Event Log i see several of this:
| Code: |
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 2011.03.29.
Time: 13:13:47
User: N/A
Computer: STREAM001
Description:
Faulting application icecastService.exe, version 0.0.0.0, faulting module icecastService.exe, version 0.0.0.0, fault address 0x0001fa49.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 69 63 65 ure ice
0018: 63 61 73 74 53 65 72 76 castServ
0020: 69 63 65 2e 65 78 65 20 ice.exe
0028: 30 2e 30 2e 30 2e 30 20 0.0.0.0
0030: 69 6e 20 69 63 65 63 61 in iceca
0038: 73 74 53 65 72 76 69 63 stServic
0040: 65 2e 65 78 65 20 30 2e e.exe 0.
0048: 30 2e 30 2e 30 20 61 74 0.0.0 at
0050: 20 6f 66 66 73 65 74 20 offset
0058: 30 30 30 31 66 61 34 39 0001fa49
|
Also we have a lot of these in the logs:
| Code: |
| [2011-03-29 11:58:08] WARN fserve/ req for file "C:\_IceCastSrv\web/rr.aac" No such file or directory |
In one single second, there are 917 such entries in the log affecting various mounts 
Any hints please? Master server is up and fine, sources not disconnected. |
|
| Back to top |
|
|
m3gab0y
Joined: 15 Aug 2009
Posts: 47
Location: London, UK
|
| Posted: Tue Mar 29, 2011 4:57 pm Post subject: |
|
|
| For me it just crashes and restarts the service, throwing away listeners... |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
