similar to: libshout : how to detect network connection lost

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

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

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

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

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

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

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

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:

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

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'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

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

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

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

The open source fdk-aac encoder, available there: https://github.com/mstorsjo/fdk-aac offers pretty good quality. As for libshout, I do not think that it is currently posible to send AAC data using it. First, libshout doesn't have support to buffer and control timing of data sent. And even is you use the un-timed API (shout_send_raw), the library cannot set the proper mime type, due to a

Mihai, Here's the full backtrace. (gdb) bt full #0 0x40292093 in strlen () from /lib/i686/libc.so.6 No symbol table info available. #1 0x40291dc5 in strdup () from /lib/i686/libc.so.6 No symbol table info available. #2 0x400aed79 in _shout_util_dict_set (dict=0x0, key=0x804b746 "song", val=0x0) at util.c:236 prev = (util_dict *) 0x80555b8 #3 0x400ad61b in

Dear list, a few weeks ago there was a short thread about ogg123 starting to stutter (http://www.xiph.org/archives/vorbis/200403/0043.html) and making static noise after streaming music for more than 3.5 hours. I have a similar problem; i used ices-2.0 to stream a playlist, and after a couple of hours (sometimes just one hour, sometimes 5 to 8 hours) i get noise or stutter. Now one thing i

Dear list, i have a test stream running (ices/2.0, icecast/2.0). It streams oggVorbis files (encoded with -q -1, mono) in an endless loop. And no matter which player i try (WinAMP 3, WinAMP 5.03, newest ogg123 from yesterday's CVS) - they all stop playing after a couple of hours. WinAMP just stops, ogg123 sometimes even crashes totally. Ices runs for days without any glitches, but