Icecast - Mar 2005 - Mounting problems...

Geoff:
> So what DSP plugin are you using?  Oddcast?  SAM? Shoutcast DSP?  Something
> else?
Oddcast DSP v3
> Is your plugin actually connnecting to Icecast?
Yes, Oddcast tells me it's broadcasting test.m3u at ~32kb (I set it
this slow) and
Icecast sees this connection.  It also sees when others connect, but
all attempts
result in Error 404
> When your friends try to connnect, how are they doing this (i.e. are they
> typing/pasting a URL into their player, clicking on a link on a website, or
> something else)?
They are typing http://myWANipaddress:portchosenforOddcast/test.m3u
> Have you tried looking in Icecast's error log?  Does it say anything
about
> the connection attempts and if so, what?
[2005-03-10  21:57:51] INFO main/main.c Icecast 2.2.0 server started
[2005-03-10  21:57:51] INFO yp/yp.c Adding new YP server
"http://dir.xiph.org/cgi-bin/yp-cgi" (timeout 15s, default interval
30s)
[2005-03-10  21:57:51] INFO stats/stats.c stats thread started
[2005-03-10  21:57:51] INFO fserve/fserve.c file serving thread started
[2005-03-10  21:57:51] INFO yp/yp.c YP update thread started
[2005-03-10  21:57:55] INFO connection/connection.c Source logging in
at mountpoint "/test.m3u"
[2005-03-10  21:59:21] INFO source/source.c Source "/test.m3u" exiting
[2005-03-10  21:59:28] INFO connection/connection.c Source logging in
at mountpoint "/test.m3u"
[2005-03-10  22:00:19] INFO source/source.c Source "/test.m3u" exiting
[2005-03-10  22:00:19] INFO connection/connection.c All connection threads down
[2005-03-10  22:00:19] INFO main/main.c Shutting down
[2005-03-10  22:00:19] INFO fserve/fserve.c file serving thread stopped
[2005-03-10  22:00:19] INFO slave/slave.c Slave thread shutdown complete
[2005-03-10  22:00:19] INFO yp/yp.c YP thread down
[2005-03-10  22:00:20] INFO stats/stats.c stats thread finished
 
This shows Oddcast connecting to Icecast, starting the YP thread, and
my futile attempts to have people connect.  I can broadcast seemingly
fine until they attempt a connection, and then my Winamp skips and
slows down, while they get a 404 error, and my Winamp continues to
skip until I disconnect Oddcast from Icecast.

My computer specs:

Windows 2000 Professional
Intel Celeron 766mhz
30 Gig HD
319mb Ram

I've noticed that also whenever anyone attempts connecting, my CPU
usage skyrockets.

Hi,

ah..  I see your problem, at least the one which prevents people from being 
able to tune in.  No idea why your Winamp is stuttering though.

the .m3u filetype is a playlist type which is used to send the actual URL 
of a stream to a player so they can open it.  Chances are that Winamp as a 
player won't handle this properly anyway since it does the broken thing of 
looking at file extensions to determine what to do with a stream, rather 
than its MIME type.

but it never gets the chance to find out.  Icecast is programmed to provide 
a playlist if you request <mountname>.m3u.  Icecast seems to be assuming 
that you'd never want to call a mountpoint anything with a .m3u extension, 
so instead of finding the mount /test.m3u, it's actually looking to serve a 
.m3u playlist for the /test mountpoint.  Since there is no /test mount, it 
returns 404.

Bug?  Maybe, maybe not.  Up to the developers to decide I suppose.  On the 
one hand, it's not doing what it probably should do.  On the other hand, 
you probably shouldn't be doing that anyway.

I recommend calling it just /test or /test.mp3

BTW: Unless you're only ever going to listen to streams from your own 
machine, I'd recommend setting the hostname to something meaningful as it 
is used in these generated .m3u playlists to point back to itself so that 
listeners can connect to streams.

Geoff.


-- 
Geoff Shang <geoff@hitsandpieces.net>
Phone: +61-418-96-5590
MSN: geoff@acbradio.org

Make sure your E-mail can be read by everyone!
http://www.betips.net/etc/evilmail.html

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

On Sat, 12 Mar 2005 00:30:58 +1000, Geoff Shang <geoff@hitsandpieces.net>
wrote:
> 
> but it never gets the chance to find out.  Icecast is programmed to provide
> a playlist if you request <mountname>.m3u.  Icecast seems to be
assuming
> that you'd never want to call a mountpoint anything with a .m3u
extension,
> so instead of finding the mount /test.m3u, it's actually looking to
serve a
> .m3u playlist for the /test mountpoint.  Since there is no /test mount, it
> returns 404.
> 
> Bug?  Maybe, maybe not.  Up to the developers to decide I suppose.  On the
> one hand, it's not doing what it probably should do.  On the other
hand,
> you probably shouldn't be doing that anyway.
> 
I think (and I haven't tested it recently, but this is how I designed
it) the /test.m3u request serving a playlist should only happen in
/test is a currently-existing mountpoint. If it isn't, the code will
continue on - and should serve the stream. It probably confuses winamp
and other buggy clients, though.

Mike