similar to: libshout crashing during pause

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

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

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

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

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

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

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

OK...messing with 'gdb' (of which I am completely new to) <p>Here's is the complete output from what I've done with 'gdb' ---------------------------------------------------------------- # gdb ices GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it

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(

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

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

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, I've been working on a customized version of ezstream and I've been noticing that with a particular setup after playing particular tracks ezstream terminates. I say terminates because there are no error messages, it just exits. I've tried this on both my version and the stock version available via icecast.org just be certain and it happens with both versions. I'm

Has anyone seen this issue before on solaris 2.7. I keep getting this error for libshout when trying to compile the example. root#[/usr/local/src/libshout-1.0.9/example]#gcc -lshout -o test example.c Undefined first referenced symbol in file socket /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.2/../../../libshout.so recv