similar to: programming with libshout

After reading this posting in the icecast archives (http://www.xiph.org/archives/icecast/3483.html) about setting the stream url in the metadata with ices2, I couldn't see that it actually was possible to set the ice-url anywhere. Please let me know if the attached patch is any use, and if I'm sending it to the right place! (Unix linefeeds). I use it with Peercast. It means you can add

I noticed the same problem in the Perl wrappers since many years ago. I ended up wrapping the libshout portion of the perl code in an eval/alarm to detect the hang and restart the libshout thread as needed. -- Randy Fast Serv Networks, LLC > Message: 1 > Date: Thu, 22 May 2008 10:14:50 +0200 > From: "tech at viewsurf" <tech at viewsurf.com> > Subject:

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()

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

On Mon, Sep 17, 2012 at 9:29 AM, George R. Welch <george at grwelch.com> wrote: > 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

On 9/17/12 12:37 PM, Michael Smith wrote: > On Mon, Sep 17, 2012 at 9:29 AM, George R. Welch <george at grwelch.com> wrote: >> 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

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:

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

Hi List, i have a problem streaming mp3's to the icecast server via libshout-2.1. Everything works fine as long as i send ogg's to the icecast server. libshout as well as icecast do not report any errors. what might be the problem? my code looks like this: shout_init() shout_set_host(...) shout_set_password(...) shout_set_mount(...) shout_open() shout_set_format(...) while(

I kind of copied the example from the distribution and changed it a bit so it would send my own lame encoded mp3 data. I decode an mp3 and encode that same data again in a lower bitrate and send that data to my icecast server. After each shout_send i use the shout_sync function but it doesn't seem to wait and just sends all available buffers at once to the icecast server. When its done sending

On 2002.11.11 11:22 Leo Currie wrote: > I'm not entirely sure. Certainly, playback is flawless with Winamp. > Every now and then, Ices seems to just stop, and swallow up all my CPU. > I'm not sure if this was caused by my playlist having non-existant file > entries, or whether it was caused by me trying to make it play mp3's. In > any case, it's been running all

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

Okay, this is interesting.... The metadata functions work fine with icecast (2.0.0) but do not work at all with NullSoft's ShoutCast server. . . Is that not supported by libshout? Just curious... Deven Deven Phillips wrote: > Okay > > Nevermind the SEGFAULT, it was string pointers in my code. Sorry > for the inconvenience. Continuing with the issue though . . . . >

Even more to consider... The metadata is working with WinAmp and RealPlayer. The concern I have is that the 'url' metadata is being misinterpreted. My url has a "-" in it, and that is getting mistranslated somewhere and WinAmp/RealPlayer then see it as artist/title information. Not good. WinAmp is supposed to display the website defined by the URL. Something else

Howdy, I''m using Apache 2.2 + Mongrel with great success, using the sample configs from the Mongrel site. We have some MP3s on the site and recently someone has been stealing them and basically leaching them from the site, linking to them from an off-site location. I''ve been trying to modify my Apache conf to check the referrer and adjust accordingly as below but no

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:

I've spent three days tracking this bug down.. I have yet to find how to fix it in the code, tho I do have a workaround which proves the nature of the bug. Sorry for the somewhat-overkill nature of explaining this bug, but some people have been doubting it so I'm going to give the evidence nessesary to prove the nature of it. If you send page-aligned data to libshout (via shout_send) it

I've spent three days tracking this bug down.. I have yet to find how to fix it in the code, tho I do have a workaround which proves the nature of the bug. Sorry for the somewhat-overkill nature of explaining this bug, but some people have been doubting it so I'm going to give the evidence nessesary to prove the nature of it. If you send page-aligned data to libshout (via shout_send) it

Hi, I'm write an icecast source client and I'd like to support streaming of AAC encoded files. Can anyone tell me if and how this can be achieved with libshout2/icecast? I've tried passing buffers of raw bytes from file to shout_send() but I can't get this work and I'm unsure of required client/server settings for AAC. Jamie -- http://www.jamiebullock.com