Hey there,
I'm trying to use mp3cast~ with Icecast 1.
Initially I had a patch where the settings messages ('passwd', 'mountpoint', etc.) for the mp3cast~ were sent when the patch was loaded and the 'connect' and 'disconnect' messages were sent in response to other events. In this setup I got all the expected messages from PD but I couldn't connect to the mp3 streams, my clients just said that Icecast was returning a 404 error.
I wondered whether perhaps it might help if I sent all the settings messages every time I sent 'connect' so I altered my patch. Now, it tells me that I'm sending a "Bad Password".
I tried altering the password in the icecast.conf file (which is very confusing and difficult on Debian) but it still doesn't like it. I wanted to tell makepasswd what password I wanted (by default it just makes up random passwords!) so I did this:
$ echo apassword | makepasswd --verbose --crypt --clearfrom=-
which seemed to work. I copied the encrypted version into my icecast.conf file. I guess thats right?
In PD, can you send send messages in any particular order? If so, would it matter what order I sent the 'connect' and 'passwd' messages to mp3cast~?
On the other hand, of course, that's probably not the problem anyway. Its more likely that my initial approach is best, I just need to find out why Icecast isn't serving up the mp3 streams...
Cheers, Richard
Richard Lewis wrote:
Hey there,
I'm trying to use mp3cast~ with Icecast 1.
stupid me, but why are you using icecast-1 instead of icecast-2 ?
I tried altering the password in the icecast.conf file (which is very confusing and difficult on Debian) but it still doesn't like it. I wanted to
what is the confusiion and difficulty in editing the configuration file (in Debian as opposed to other systems)? usually it is as simple as opening the file with a text-editor (and the correct permissions).
tell makepasswd what password I wanted (by default it just makes up random passwords!) so I did this:
well, this is what makepasswd does by definition. it "Generates true random passwords by using the /dev/random feature of Linux"
$ echo apassword | makepasswd --verbose --crypt --clearfrom=-
which seemed to work. I copied the encrypted version into my icecast.conf file. I guess thats right?
i might be totally wrong here, but to my knowledge, icecast stores passwords in plaintexts.
In PD, can you send send messages in any particular order? If so, would it
yes, you can send messages in any order. but be aware that it depends on the objects you are sending messages too whether the order is important. e.g. sending "hello" and "you" to print will result in "hello you", whereas sending "you" and then "hello", will result in "you hello", which is something different.
(ok, that was just a joke, but it is still true that it depends on the object whether order matters or not)
matter what order I sent the 'connect' and 'passwd' messages to mp3cast~?
i think(! without reading the code), that following is happening: the "passwd" message stores the password in [mp3cast~] for later use. when you send it the [connect( message, it will use the previously stored password to connect to the server. so in this case it is _very important_ that you first send the [passwd( message and then send the [connect( message (else [mp3cast~] would try to connect to the server with an empty/default password)
mfg.asdr IOhannes
On Monday 19 February 2007 16:03, you wrote:
Richard Lewis wrote:
Hey there,
I'm trying to use mp3cast~ with Icecast 1.
stupid me, but why are you using icecast-1 instead of icecast-2 ?
Its another Debian problem: the icecast2 package in Debian is ogg only.
i might be totally wrong here, but to my knowledge, icecast stores passwords in plaintexts.
In Debian, icecast is compiled with encrypted passwords option.
i think(! without reading the code), that following is happening: the "passwd" message stores the password in [mp3cast~] for later use. when you send it the [connect( message, it will use the previously stored password to connect to the server. so in this case it is _very important_ that you first send the [passwd( message and then send the [connect( message (else [mp3cast~] would try to connect to the server with an empty/default password)
OK, I've verified that its not a password problem now. The mp3cast~ documentation doesn't seem to mention this.
BTW, thanks for your reply regarding the -nogui option and setting dsp 1. I've just read it on the PD-list archive (as I seem to have intermittent mail delivery from PD-list!) and added it to my patch. Its obviously important, but I still can't connect to my mp3 streams :-(
Cheers, Richard
hello Richard
On Mon, 2007-02-19 at 15:15 +0000, Richard Lewis wrote:
Hey there,
I'm trying to use mp3cast~ with Icecast 1.
Initially I had a patch where the settings messages ('passwd', 'mountpoint', etc.) for the mp3cast~ were sent when the patch was loaded and the 'connect' and 'disconnect' messages were sent in response to other events. In this setup I got all the expected messages from PD but I couldn't connect to the mp3 streams, my clients just said that Icecast was returning a 404 error.
[mp3cast~]'s output on the pd-window should give you a hint, whether it could connect to the icecast-server or not. if nothing tells you, that connection failed or something like that, i would assume that it could connect correctly and that the problem might be with the connection between client-app and server.
some random possible problems, that come to my mind:
-did you try to connect the client on the right port (e.g. http://yourhost.com:8080/yourstream.mp3 ) ?
-is the port not blocked by a firewall?
I wondered whether perhaps it might help if I sent all the settings messages every time I sent 'connect' so I altered my patch. Now, it tells me that I'm sending a "Bad Password".
the only thing i know, is that before the [connect(-messages all other settings-messages should be sent.
I tried altering the password in the icecast.conf file (which is very confusing and difficult on Debian) but it still doesn't like it. I wanted to tell makepasswd what password I wanted (by default it just makes up random passwords!) so I did this:
$ echo apassword | makepasswd --verbose --crypt --clearfrom=-
hm.... my icecast-server (v2.3.1) has a configuration-file called icecast.xml, where the password is written in plain-text (the file is in xml-format). so no makepasswd and stuff is needed. i don't know if icecast.conf works differently.
which seemed to work. I copied the encrypted version into my icecast.conf file. I guess thats right?
In PD, can you send send messages in any particular order? If so, would it matter what order I sent the 'connect' and 'passwd' messages to mp3cast~?
yes, you can send the messages in a certain order in pd and yes, it DOES matter when sending the settings-messages to [mp3cast~]. first set all settings like passwd, mountpoint, bitrate etc and after this send the [connect blabla.com 8080(-message. you could put all settings-messages in one single message-box, separated by a ',' like for example:
[name streamname, mountpoint yourstream.mp3, icecast2, password yourpasswd, mpeg 44100 128 1 4(
good luck roman
On the other hand, of course, that's probably not the problem anyway. Its more likely that my initial approach is best, I just need to find out why Icecast isn't serving up the mp3 streams...
Cheers, Richard
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Monday 19 February 2007 16:09, Roman Haefeli wrote:
hello Richard
On Mon, 2007-02-19 at 15:15 +0000, Richard Lewis wrote:
Hey there,
I'm trying to use mp3cast~ with Icecast 1.
Initially I had a patch where the settings messages ('passwd', 'mountpoint', etc.) for the mp3cast~ were sent when the patch was loaded and the 'connect' and 'disconnect' messages were sent in response to other events. In this setup I got all the expected messages from PD but I couldn't connect to the mp3 streams, my clients just said that Icecast was returning a 404 error.
[mp3cast~]'s output on the pd-window should give you a hint, whether it could connect to the icecast-server or not. if nothing tells you, that connection failed or something like that, i would assume that it could connect correctly and that the problem might be with the connection between client-app and server.
Yes, I can't see the patch window because its -nogui. But I can see pd's output and it now looks as though its connecting properly:
mp3cast~: connecting to port 8080 mp3cast~: logging in to IceCast server... mp3cast~: logged in to localhost.localdomain mp3cast~ : using lame version : 3.97 mp3cast~ : lame initialization done. (1) mp3cast~: initialising buffers
some random possible problems, that come to my mind:
-did you try to connect the client on the right port (e.g. http://yourhost.com:8080/yourstream.mp3 ) ?
Yes, I keep checking this. Another things I might try is playing with the hostname setting in Icecast. Maybe just localhost isn't good enough and it might have to be the same as the hostname that clients give...
-is the port not blocked by a firewall?
No, I've made sure that my computer can talk to port 8080 (and my test server doesn't have a firewall!!)
I wondered whether perhaps it might help if I sent all the settings messages every time I sent 'connect' so I altered my patch. Now, it tells me that I'm sending a "Bad Password".
the only thing i know, is that before the [connect(-messages all other settings-messages should be sent.
$ echo apassword | makepasswd --verbose --crypt --clearfrom=-
hm.... my icecast-server (v2.3.1) has a configuration-file called icecast.xml, where the password is written in plain-text (the file is in xml-format). so no makepasswd and stuff is needed. i don't know if icecast.conf works differently.
Debian icecast is compiled with encrypted passwords option.
which seemed to work. I copied the encrypted version into my icecast.conf file. I guess thats right?
In PD, can you send send messages in any particular order? If so, would it matter what order I sent the 'connect' and 'passwd' messages to mp3cast~?
yes, you can send the messages in a certain order in pd and yes, it DOES matter when sending the settings-messages to [mp3cast~]. first set all settings like passwd, mountpoint, bitrate etc and after this send the [connect blabla.com 8080(-message. you could put all settings-messages in one single message-box, separated by a ',' like for example:
OK, thanks. I don't think this is a password issue any more.
Cheers, Richard
Richard Lewis wrote:
On Monday 19 February 2007 16:09, Roman Haefeli wrote:
-did you try to connect the client on the right port (e.g. http://yourhost.com:8080/yourstream.mp3 ) ?
Yes, I keep checking this. Another things I might try is playing with the hostname setting in Icecast. Maybe just localhost isn't good enough and it might have to be the same as the hostname that clients give...
it might well be, that icecast only binds to the public interface (e.g. "eth0") and NOT to the loopback-device ("lo", that's the one that reacts on 127.0.0.1 or "localhost").
you can debug this by trying to connect to icecast with telnet and the 2 ip's.
another option is, that /etc/hosts.(allow|deny) restrict access to the loopback-devices.
mfg.asdr IOhannes
On Monday 19 February 2007 16:09, Roman Haefeli wrote:
Richard Lewis wrote:
On Monday 19 February 2007 16:09, Roman Haefeli wrote:
-did you try to connect the client on the right port (e.g. http://yourhost.com:8080/yourstream.mp3 ) ?
Yes, I keep checking this. Another things I might try is playing with the hostname setting in Icecast. Maybe just localhost isn't good enough and it might have to be the same as the hostname that clients give...
it might well be, that icecast only binds to the public interface (e.g. "eth0") and NOT to the loopback-device ("lo", that's the one that reacts on 127.0.0.1 or "localhost").
you can debug this by trying to connect to icecast with telnet and the 2 ip's.
another option is, that /etc/hosts.(allow|deny) restrict access to the loopback-devices.
OK. I think I've got this now: I've made sure that the server_name property in icecast.conf and the host name used in the 'connect' messages to all my mp3cast~ objects are the same and now it seems to be working!
Thanks for your help, everyone!
Cheers, Richard
-
IOhannes m zmoelnig -
Richard Lewis -
Roman Haefeli