similar to: libshout and mp3 streaming?

I've tried everything I know how (and a lot I don't) to get ices to compile on this beige G3 ppc box. I've got the latest cvs of libshout and ices. Gentoo linux ppc 1.2-r1, from stage3 tarball. gcc 2.95.3 I've made sure that libshout points to libshout.so.2.0.2. Don't know what else to try. I've got the box here, and I've port-forwarded through my firewall to

Attached is a patch against shout-python-0.2 which does two trivial but very useful things (1) The function "get_connected" is exported so that shout-python becomes usable in nonblocking mode. In the current version of shout-python "open" raises an exception in nonblocking mode. (2) The global interpreter lock is released in the potentially blocking functions

I propose the following changes to the libshout API to support nonblocking I/O: New functions: int shout_set_nonblocking(shout_t *self, unsigned int nonblocking): Instructs libshout to use nonblocking I/O. Must be called before shout_open (no switching back and forth midstream at the moment). unsigned int shout_get_nonblocking(shout_t *self): self-explanatory. Changed functions:

I get this error every time I try to start ices: ices: relocation error: ices: undefined symbol: resolver_initialize I'm running a Celeron with 64MB of RAM which up until last moth, ran ices with absolutely no complaint. Here are the steps I've taken to resolve this problem: Full update from debian/unstable -no effect Full reinstall of all dependencies using CVS checkouts -ices fails

Hi, I have successfully gotten the libshout-2.0 release to compile under gcc/MingGW ('gcc -mno-cygwin', version 'gcc (GCC) 3.3.1 (cygming special)'), after applying Leigh Smith's patches as posted on this list (http://www.xiph.org/archives/icecast-dev/0660.html). I have then generated a dll and wrapped it in JNI using the stubs from libshout-java

I'm getting errors like; /tmp/ccJK5HgU.o(.text+0x426): In function `connect(shout*, std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': : undefined reference to `shout_open' for each of the ices function calls. My gcc command looks like this; g++ -o myicestream -L/usr/lib/shout -lmysqlclient myicestream.cpp and libshout is in; find /usr -name

Thanks ! changed the format to MP3, am getting the icecast stream now. Just realized that esound is capturing the microphone input, wanted to stream the music being played by itunes (basically something like hijacking+streaming the audio). This dosent come under icecast, just wondering if u know of anything related. Dwipal On Dec 31, 2004, at 6:00 PM, Geoff Shang wrote: Dwipal Desai wrote:

Hi all, I've just released beta 2 of libshout 2.0, the icecast 2 compatible streaming library. http://xiph.org/~brendan/beta/libshout-2.0b2.tar.gz Libshout 2.0 adds support for icecast 2, Ogg streaming, and IPv6. Ogg and Vorbis are now prerequisites. Changes since beta 1: * lots and lots of autoconf. Thanks to Karl Heyes for his help here. * a fix for unusual MP3 bitrates contributed by

Hi all, I've just released beta 2 of libshout 2.0, the icecast 2 compatible streaming library. http://xiph.org/~brendan/beta/libshout-2.0b2.tar.gz Libshout 2.0 adds support for icecast 2, Ogg streaming, and IPv6. Ogg and Vorbis are now prerequisites. Changes since beta 1: * lots and lots of autoconf. Thanks to Karl Heyes for his help here. * a fix for unusual MP3 bitrates contributed by

We (Mixxx) have a user who reported an issue with hostname resolution. Here's the bug report: https://bugs.launchpad.net/mixxx/+bug/1391654 They say their hostname resolves to both ipv4 and ipv6 and they bound icecast to the ipv4 interfaces. (I'm not sure why they don't bind to both). Mixxx cannot connect to icecast presumably because libshout is resolving and connecting to the ipv6

>This is in subversion now. I'll try to get a new release out this >weekend. Thanks! Thanks! But I noticed that giving up the global interpretor lock in a few functions allows other threads to do something stupid (like deleting the shout object during a write). So for everything to be absolutely thread safe a python shout object should contain a mutex and there should be appropriate

libshout 2.2.2 has just been released. From the NEWS file: * Handle Oggs that don't begin with zero granulepos. * Install header in correct location (broken in 2.2.1). * Theora memory leak fix. * Non-blocking shout_open was failing unnecessarily in the connect_pending state. * Cast some size_ts to ints for display purposes. You can find it at http://www.icecast.org/download.php when (if)

Hello I've configured the 'example.c' with the right SERVER, PORT, SHOUT FORMAT and all the required stuff, it works fine (the setup shout_set...() calls) but when reaching shout_open() it returns a socket error. $ ./example Error connecting: Socket error The configuration of the server and example.c is right, at least the server is up and running, and tried it with the

Hello... I have a doubt with the use of shout_send()... at low level, what should it send? the example reads from "stdin" and sends the read buffer with shout_send, but... where should fread() read from (behind the stdin)? I could think about something like this (for example) mpg123 "audio_file" ---> stdout --pipe-- stdin <--- libshout_application I include the

In the absence of any negative feedback (or positive, for that matter), I've decided to just go ahead and drop the new version of libshout, libshout 2.1. New features: * nonblocking I/O: call shout_set_nonblocking(1) before shout_open. If the socket is busy, your data will be queued until the next time libshout attempts a write. The current queue length in bytes is visible through

/bin/sh ../libtool --mode=link gcc -I/usr/include/libxml2 -pthread -g -O2 -o ices input.o cfgparse.o stream.o ices.o signals.o im_playlist.o reencode.o encode.o playlist_basic.o im_stdinpcm.o stream_shared.o metadata.o playlist_script.o audio.o resample.o im_oss.o log/libicelog.la timing/libicetiming.la thread/libicethread.la avl/libiceavl.la -lvorbisenc -L/usr/local/lib -lshout -lvorbis

Hello. For various reasons I am writing my own source client. Most things seem to be working well. Connections work. shout_send() and shout_sync() seem to behave as expected. However, I find that if more than about 10-20 seconds passes between shout_send() calls then libshout crashes (takes my client down) during a subsequent shout_send(). Are there any rules about how often shout_send()

Hi Geoff! Thanks for ur reply Is there a way to tell icecast that the stream is mp3 ? Mac OS X has another way of live streaming using Quicktime Broadcaster, however, i am not able to make it work with MPlayer2. It works file with a quicktime client. There seems to be some issues with the SDP files that Quicktime creates for playing the audio and mplayer. Nicecast is kindof exactly what i

Hello, I have the following problem: I successfully installed R (Version 2.1.3.0 for Windows) on my Notebook (Windows 7) in June. Now I used the same setup file for a PC (Windows XP) and got a message from the anti virus software (Avira), that the setup file contains the Trojan "TR/ATRAPS.Gen". The PC is never connected to the internet, this is why the anti virus software has

I've written a first draft of python bindings for libshout 2: http://xiph.org/~brendan/pyshout2/pyshout2-0.0.1.tar.gz Comments welcome. I've never written a python extension before so I'm sure there's plenty of room for improvement. But it works for me. -b --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To