similar to: directory servers and stuttering

: : Try 1.3.8 as well, maybe the updated connect code didn't go in until : : then. : Will do. I'll report back after I've had a chance to compile and set : that version up. Initial tests with v1.3.8beta2 seem to solve the problem. To test, I've added two bogus directory servers to the configuration which it cannot possibly connect to and when it goes to touch, there doesn't

I'm running Icecast v1.3.7 and I've recently noticed there's a direct correlation between a stream "stuttering" and the icecast process having difficulty contacting one or more directory servers. In short, if icecast can't connect to a directory server, then it tends to affect the playback on the stream, such that clients will typically get dropped with message such as

One question though - how do I create a pseudo user? Thanks, Andrew On Sun, 25 Feb 2001, Michael Faurot wrote: > In article <983130226.25873@phzzzt.atww.org> you wrote: > > : 1) With regards to the recent buffer-overflow exploit and the > : recommendation of running icecast as a non-root user, how exactly does > : one do that? > > I do it via "su". I use

In article <983130226.25873@phzzzt.atww.org> you wrote: : 1) With regards to the recent buffer-overflow exploit and the : recommendation of running icecast as a non-root user, how exactly does : one do that? I do it via "su". I use a pseudo user named "ice" and have this in a shell program that starts icecast: exec su --login -c

Alexander Newald <alexander@newald.de> wrote: : Compiling went fine, but execution is a problem: [...] : --- SIGSEGV (Segmentation fault) --- : +++ killed by SIGSEGV +++ [...] : I used the config files of the previos version : Some hints... Same situation here (also used previous configuration file from v1.3.8beta). RedHat v6.X, kernel 2.2.17 (with RedHat's patches). --

: A piece of new code which should only get included on older systems was : getting compiled in anyway. That's been fixed. new tarballs and rpms : are on the site (same version number, but the rpms have -2 now). That seems to have done the trick. Thanks. BTW, is CVS the only way to get libshout? I didn't see a link for it at http://www.icecast.org/download.html. --

You're going to need root access. Presumably you have it if you have control over icecast. You could do a simple adduser. Then use your favorite editor and open up the /etc/passwd file (again as root). You'll need to read up on what each of the fields are, but in short you'll want to * the password field for that new user. You'll also want to change the shell to /bin/false.

On 28/08/13 23:03, Sam Varshavchik wrote: > I'm running xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64 and > xorg-x11-server-Xorg-1.14.2-9.fc19.x86_64 > > On the following chipset, the display suffers from "stuttering": > > 06:00.0 VGA compatible controller: NVIDIA Corporation GT200b [GeForce > GTX 285] (rev a1) (prog-if 00 [VGA controller]) > Subsystem:

Hi, I've been getting reports of stuttering audio in my VoIP application that uses Speex 1.1.11. Since I haven't had this report with previous versions of Speex I was wondering if one of the bug fixes in 1.1.12 solves a bug which causes the stuttering. To me the stuttering report sounds like the decoder state that speex uses gets messed up. Some info, I use the floating point version of

After one minute of connection the stream from our icecast 1.3.10 server (debian package 1.3.10-2) starts stuttering. And after some stuttering the client is disconnected by the server. The usual client is a windows winamp. The icecast logs shows that the the client is not receiving data fast enough. A small part out the logs is shown below. That the data is not received fast enough is rediculous

hi Neologism, i can play flac from my server to my workstation via nfs. i have a 100BaseT line as well. i only get stuttering when i'm copying files at the same time as listening. i'm using xmms. perhaps something is not set up correctly. maybe the unit doesn't have enough processing power to deal with the bandwidth usage (i am unfamiliar with the unit though). anyway just thought

I'm running xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64 and xorg-x11-server- Xorg-1.14.2-9.fc19.x86_64 On the following chipset, the display suffers from "stuttering": 06:00.0 VGA compatible controller: NVIDIA Corporation GT200b [GeForce GTX 285] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device 34c9 Control: I/O+ Mem+ BusMaster+

Dear List, After some googling around without any results, I'm quite puzzled. Since some past update I can't precise, kernel 2.6.164 works fine, however 2.6.194 has some sound problem in my somewhat old and beaten Toshiba laptop. -Audacious plays OK but other applications have problems. -For instance, mplayer acts quirky: when I pause a playing video, sound keeps stuttering endlessly. The

> A good number have id3v2 tags... say 20-30%. Do you find that it's stuttering on id3v2 files? Since those contain data that is counted by the timing code, but not played the the player, that seems a likely suspect. Ie, you'll get _playable_ data too slow. Try a stream with _no_ id3v2 files and see if the problem persists. > > What version of linux? glibc? > > RH 7.2

Hi there, I recently found a workaround for the "stuttering legs" bug in WoW, which is currently described in AppDB. It should work for everyone using gnome - so, since this is widespread, I thought it would be a good idea to share the workaround with you. I noticed that the running animation is all okay when activating auto-run - and that holding down the "run forward" key

Hi Jack, interesting that you should mention NTP. With the problem that I am having, I am getting actual libshout errors. I have run all my mp3s through mp3check and my disk subsystem is 7200 RPM SCSI. Why would NTP cause issues? ----- Original Message ----- From: "Jack Moffitt" <jack@xiph.org> To: <icecast@xiph.org> Sent: Wednesday, February 06, 2002 1:48 PM Subject: Re:

Stupid question - how do you increase your buffer size? Gary ----- Original Message ----- From: "Jack Moffitt" <jack@xiph.org> To: <icecast@xiph.org> Sent: Wednesday, February 06, 2002 1:48 PM Subject: Re: [icecast] Stuttering stream <p>> > Done, and it's working... but not significantly better than before. > > Whereas before I couldn't clear a

On Wed, 6 Feb 2002, Jack Moffitt wrote: > > A good number have id3v2 tags... say 20-30%. > > Do you find that it's stuttering on id3v2 files? Since those contain > data that is counted by the timing code, but not played the the player, > that seems a likely suspect. Ie, you'll get _playable_ data too slow. I replaced my normal playlist with a much smaller one of files

May sound like a strange question, but I am inferring from your note that you can take a lower bitrate mp3 and reencode to higher bitrate? I was always under the impression that you could go down, but not up because the required information was no longer within the mp3 file in order to step it up. If in fact this is the case, are there any requirements? i.e. does the sample rate need to be 44.1

Hi All, * is running a dream now, however we have an odd problem that I am sure some guru will be able to sort out for me in no time!! When receiving or making a call about 60 seconds or so into the call we develop choppy/stutter audio problems. It then seems to clear itself only to return again, and so the pattern carries on! This has got me stumped! Our equipment is SipTone II handsets, AVM