similar to: [PATCHES] Smartjog PatchDump

Updated version of video preview covering frame writing every 3 keyframe and a xsl typo. Best regards :) kysucix -- Make things as simple as possible, but no simpler. - Albert Einstein

Hi. Here it is my patch to put a video preview of a theora stream in status.xsl. I just added a: <video-preview>1</video-preview> parameters in icecast.xml.in that control the previewing function. It encodes a png in $webroot/$mountname.tmp and then move it to $webroot/$mountname.png As for now it saves a frame every theora keyframe, which is probably too heavy for the server but

Hi Karl, Thanks for your help, About the "Connection:" header, you are right, it's: "Connection: close" and NOT "Connection: keep-alive". The protocol when the SERVER sends the data is http 1.0. It's http 1.1 when the browser requests the data. I don't understand the "Content-Length: 54000000" header either. Also I noticed the flash player on

Here is a patch for icecast 2.3.2 that adds support for listening to mp3 and aac+ streams on the iphone. A quick background on the technical aspects of the patch and why it is needed : With the advent of 3g on the iphone, lots of people have been jumping on the bandwagon of providing internet radio streams that work on the iPhone. The biggest problem is that (without having to install an

Ok here's the deal. I set up Icecast and Oddcast, got them to communicate properly, but cannot access the live audio remotely. On other computers in the LAN it works perfetly. Currently I operate wirelessly behind a D-Link 514 router (a mite outdated by now, yes?) and have opened all necessary ports, turned my firewalls off, set this computer as a DMZ, pretty much everything I can think of -

changes, there are lots of formatting changes, and things like additions of "XXX: ..." comments that don't say anything helpful - these will need removing before the patches are really reviewable. A higher-level description of what you're attempting to accomplish with these patchsets would also be very helpful - but much more detail than "performance and reliability".

hem here it is the patch. ;) bye kysucix -------------- next part -------------- Index: conf/icecast.xml.in =================================================================== --- conf/icecast.xml.in (revisione 10365) +++ conf/icecast.xml.in (copia locale) @@ -62,6 +62,7 @@ <port>8001</port> </listen-socket> --> +

I am new to your lists but I have found something in icecast 2.3.1 that may need further review. there is a segfault when you have a failover mount point and the failover mount is using ezstream and you restart ices-2.x and the clients fail back. found via gdb. Very short diff to format.c line 104 below. diff -urNab icecast-2.3.1.orig/src/format.c icecast-2.3.1/src/format.c ---

> you can't keep them in the main queue because you are subject to the > queue size cutoff so you either keep this within the per codec handle > structure (codec list) and/or in the block for the header pages (via the > associated pointer). The sending handlers are not really codec aware > but they do notice a change in headers. Yes, but that's the problem I'm facing:

On Sunday 19 January 2003 03:35, Michael Smith shaped the electrons to shout: > There's a bad interaction here between the predata and this faststart. > Suppose we have two logical streams (A and B), and the stream has just > recently got to logical stream B. Now, this means the fast start queue > contains the end of stream A, then the stream B headers, then the start > of

On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons to shout: > We can't just drop packets, the transmission model assumed by the > format handlers (and required by at least one of them) will not permit It's not vorbis. Does it? > us to drop any data. It'd be possible, in theory at least, to tag > buffers with a flag to say that they can be dropped, but

On Friday 17 January 2003 20:17, Karl Heyes shaped the electrons to say: > I would suggest a slightly different approach. > > Instead of increasing the syscall overhead for all sockets, trapping > for uncommon cases. Try the sock_write_bytes and if that is > continuously having to queue (ie not all data can be sent) then display > the warning, maybe make it a run-time option

On Sun, 25 Apr 2004, Wild Karl-Heinz wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x08057f50 in format_mp3_write_buf_to_client (self=0x80bee00, client=0x80d5e00) > at format_mp3.c:311 > 311 if (ret < (int)refbuf->associated->len) > > what else can i do? When you get to this point, you should do a backtrace so Karl can see what is

On Saturday 18 January 2003 16:04, Michael Smith shaped the electrons to shout: > On Sunday 19 January 2003 01:59, Ricardo Galli wrote: > > On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons > > to > > > > shout: > > > We can't just drop packets, the transmission model assumed by the > > > format handlers (and required by at

I'm trying to get icecast 2.3.1 compiled on a slackware 10.0 box. I've successfully compiled the libshout libraries. Now this is what I got after a make in the source dir: > make[3]: Entering directory `/tar_archive/icecast-2.3.1/src' > /bin/sh ../libtool --mode=link gcc -pthread -g -O2 -L/usr/local/lib > -o icecast cfgfile.o main.o logging.o sighandler.o connection.o

Hi, find enclosed a patch to implement faststart (or prebuffering). Basically, it stores a number of "refbuf"s, configurable by seconds. When a new client connects, it adds the prebuffers to que clients' queue so they are delivered as fast as permitted by the connection. As result, the players prebuffers are filled up faster giving a better "response". I tried

Hello, I'm a new user of icecast which is a really cool software. I use it with the the http proxy module of apache httpd to do port forwarding with 2 sub domains. On my router i forward all tcp traffic of the port 80 to my server. 2 Sub domains are redirected to my server : radio.mydomain.com (icecast) music.mydomain.com (ampache) my apache server host the ampache application with a

Below is a fix for the current problem of checksum offload not working in a NAT''ed network. The cause is the NAT/iptables code incorrectly modifying the TCP/UDP checksum (for the checksum offload case). The original code assumes a valid checksum, which is not the case for checksum offload packets (which has a complimented, partial checksum for the hardware to use). The fix is to

In message "[icecast] icecast-2.0-kh34" on 24.04.2004, Karl Heyes <karl@xiph.org> writes: KH> On Fri, 2004-04-23 at 09:58, Wild Karl-Heinz wrote: KH> ... [snip] >> ... but it coredumps every 10 secs. KH> There is a segv bug in kh34 triggered when clients move from one mount KH> to another. That should be fixed now in kh35. the result with gdb .... (gdb)