similar to: Stuttering stream

on 2/6/02 10:19 AM, Jack Moffitt at jack@xiph.org wrote: >> It's not my bandwidth from the server... a week ago, I was streaming >> Shoutcast from Windows with no problems. It's not my bandwidth at work >> (where I'm listening), I can pull in other 128k streams with no problem. >> >> Help? > > Where is shout? > > And you shouldn't be

On Wed, 6 Feb 2002, Jack Moffitt wrote: > ices is built on libshout. libshout should have perfect timing and it > also detects and discards corrupt frames and supports VBR streams. It > is basically the _new_ version of shout. ices refuses to load. It whines about libmp3lame.so.0 being missing. I found the message in the archives that supposedly forces ices to compile with lame

On Wed, 20 Feb 2002, Gary Major wrote: > To define this list you put the full path to your mp3 directory in your > icecast.conf file. It has been awhile since I set this up, and I forget the > exact option, although static template comes to mind. This is great... but it's not showing a full listing of what's in my directory. My MP3 collection is housed in /music/. There are

> 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

I'm running RedHat 7.2 (kernel 2.4.17) on a PII 300. I'm using Liveice with XMMS. I had no problem broadcasting with Shoutcast and Winamp back before I switched over to Linux. I'd love to get going on broadcasting... but Icecast refusing to open is a problem. Running icecast gives me the following. Starting thread engine... [04/Feb/2002:13:57:38] Icecast Version 1.3.10 Starting..

> > What kidn of files are you streaming? > > MP3s and nothing but. Are they high bitrate? VBR? Do they have id3v2 tags? We could all guess they were mp3s :) <p>What version of linux? glibc? Icecast 1.3.11? jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to

Expanding on Jack's note. In a default lame install, the lame library in in /usr/local/lib which is not in the 'trusted' library directories, hence why the linker/loader can't find it. What you need to do to fix it (as root), is open up /etc/ld.so.conf and add /usr/local/lib to the file. This file just contains various paths that will be searched in addition to /usr/lib & /lib

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

On Wed, 6 Feb 2002, Jack Moffitt wrote: > THen I suggest you start to look elsewhere for your problem. libshout > is quite well tested and every time someone has thought it was skipping, > it turned out to be NTP chaning their clock or a slow harddrive or > something similar. I'm saying "Here's this problem I'm having, how do I fix it?" I don't care if the

> Done, and it's working... but not significantly better than before. > Whereas before I couldn't clear a single song without the stream devolving > into skipping, now I'm averaging between 15-20 minutes. Better, but still > not acceptable. THen I suggest you start to look elsewhere for your problem. libshout is quite well tested and every time someone has thought it was

What you could do, if you were so inclined, is to write a shell script that would cycle through your directories and create symbolic links in your main directory. Not pretty at all, but would solve your issue. Alternatively, a script could be written to cycle through your directories to create a custom web page to display ALL songs. A little prettier and again would solve your issue. My script

How do I submit an email to icecast? -----Original Message----- From: Gary Major [mailto:gr_major@hotmail.com] Sent: Wednesday, February 20, 2002 1:34 PM To: icecast@xiph.org Subject: Re: [icecast] ideas for on-demand streaming <p>What you could do, if you were so inclined, is to write a shell script that would cycle through your directories and create symbolic links in your main

I guess that answers my question :P -----Original Message----- From: Hathaway, Shaun Sent: Wednesday, March 13, 2002 8:24 AM To: icecast@xiph.org Subject: RE: [icecast] ideas for on-demand streaming <p>How do I submit an email to icecast? -----Original Message----- From: Gary Major [mailto:gr_major@hotmail.com] Sent: Wednesday, February 20, 2002 1:34 PM To: icecast@xiph.org Subject: Re:

hey folks, i'm setting up an archive of mp3s and need to get an on-demand streaming solution up. i've got icecast running well and the streaming is great. the thing is that i need to let folks click a link and start listening from the beginning of an audio file. seems like i could script something to start up a new stream for each user and serve them up a unique url, but that seems a

> No, what I meant by instances was multiple non-forked instances of the > executable in the process table, ie icecast run multiple times with different > port options. I see from your answer below that this is no longer possible. If you run multiple copies of icecast, they will be completely separate, and work as two separate entities. I have run many instances of icecast on the same

This reminds me of a problem I've been having occasionally with ices... once in a while, instead of properly decoding and re-encoding the MP3 for my stream, it'll stream gibberish (basically, it sounds like a "cooked" MP3). After that, maybe 1 time out of 3, it'll segfault and crash. Even in verbose mode, ices doesn't report anything other than "resyncing".

(By the way, upgrading to .11 seemed to take care of the skipping. Thanks!) The stream seems to be working just fine, although Winamp is showing bandwidth at 130 or higher, occasionally up to 145 or so. Most of my MP3s are 128 kbps, and ices should be re-encoding everything as 128 anyway. This is really a minor issue... but I'm wondering what could be taking up the extra bandwidth? Or

Hello Sirs, > > Have you ran them through mp3check and mp3_check? > >Yep. Found a couple with a few bad frames and deleted them. Other than >that, nothing worse than a missing ID3 tag or two. Could you please give me the address of these tool(mp3check, mp3_check). I have many bad coded mp3, When Icecast streaming these bad! mp3s it kicks the connected clients. I want to delete

Von: Gesendet: 07/12/01 05:12 An: "icecast@xiph.org" <icecast@xiph.org> Betreff: [icecast] shout - icedir - iceplay ! CC: ---------------------------------------------- > i read on the icecast page .. i can use > iceplay or shout for playing mp3 ! oK .. i was search on rpmfind.net .. and there was nothing .. and i try it again .. and now .. AHH ! oK .. now i have iceplay

I'm running icecast 3.1.10 (from the ports collection) on a freebsd 4.3 machine with a hacked version of iceplay doing the encoding. With older version of icecast you could start multiple instances and tell iceplay to broadcast to each one of those instances with a different playlist. This version of icecast seems to only run one instance, even if I try to start more than one. So, I've