Hi there.

I have problem with Mount Points.
I'm setting  new mount point with different bitrate.
i.e.
1 /stream - 128kbps
2 /stream2 - 64kbps

After that /stream have the same bitrate as /stream2 and /stream2 doesn't work.

Wierd thing is that when i go to http://mydomain.pl:8000/stream6 <- whatever number at the end, it's giving me still stream from /stream2 but /stream2 is still as "unavailible".

If I'll delete /stream2 everything is going back to norma with bitrate in /stream but /stream(anynumber) still playing including /stream2.

Live example at:

http://82.165.143.149:8002  - stream have 2 mount points "/stream" (160 kbps) and "/stream2"(96kbps)

http://82.165.143.149:8006/stream -  have just one mount point.

Another problem is that I can't install IceCast with centova update command

"/usr/local/centovacast/sbin/update"

i get following error:

Code: [Select]

/usr/bin/ld: cannot find -lxml2
collect2: ld returned 1 exit status
make[3]: *** [icecast] Error 1
make[3]: Leaving directory `/root/rpmbuild/BUILD/icecast-2.3.2/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/rpmbuild/BUILD/icecast-2.3.2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/icecast-2.3.2'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.cfqW8d (%build)


RPM build errors:
    user karl does not exist - using root
    group karl does not exist - using root
    Bad exit status from /var/tmp/rpm-tmp.cfqW8d (%build)
rpmbuild exited with error; check your rpmbuild configuration
Installer exited with error, aborting

CentOS 6.2 (Final) x64

I have problem with Mount Points.
I'm setting  new mount point with different bitrate.
i.e.
1 /stream - 128kbps
2 /stream2 - 64kbps

After that /stream have the same bitrate as /stream2

Hmm OK, I'll have to look into that to see if I can reproduce it.

and /stream2 doesn't work.

How so?

Wierd thing is that when i go to http://mydomain.pl:8000/stream6 <- whatever number at the end, it's giving me still stream from /stream2 but /stream2 is still as "unavailible".

That's internal to ShoutCast DNAS so I can't speculate on why it'd do that -- the folks at Nullsoft would be the right people to ask about that.

http://82.165.143.149:8002  - stream have 2 mount points "/stream" (160 kbps) and "/stream2"(96kbps)

At the moment you have just one (Stream #1).

http://82.165.143.149:8006/stream -  have just one mount point.

/stream *is* a mount point, so it's not going to list any other mount points.

/usr/bin/ld: cannot find -lxml2

That means your server's package configuration is somehow broken.  Before the CC installer tries to build the IceCast SRPM it uses yum to install libxslt-devel, which depends upon libxml2-devel (meaning that yum automatically installs it when you install libxslt-devel).  The above is saying that libxml2-devel can't be found... which is impossible if yum installed libxslt-devel correctly.  CC checks if yum reported any errors and will terminate the installation if it did... so yum clearly exited without errors but did not install the packages it was told to install.

and /stream2 doesn't work.

How so?

Wierd thing is that when i go to http://mydomain.pl:8000/stream6 <- whatever number at the end, it's giving me still stream from /stream2 but /stream2 is still as "unavailible".

That's internal to ShoutCast DNAS so I can't speculate on why it'd do that -- the folks at Nullsoft would be the right people to ask about that.

http://82.165.143.149:8002  - stream have 2 mount points "/stream" (160 kbps) and "/stream2"(96kbps)

At the moment you have just one (Stream #1).

For this address: http://82.165.143.149:8002
mount points are seted up i CentovaCast Panel but aren't shown in the Shoutcast server as shown in attachments and there is that problem with quality settings (bitrate,encoder etc) which I mentioned in my first post.

Ihave fixed problem with -lxml2 but I'm still getting this error (it's trying to get to some red had directory but i've got CentOS ?):

Code: [Select]


Wrote: /root/rpmbuild/RPMS/x86_64/icecast-2.3.2-0.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.zpVphq
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd icecast-2.3.2
+ '[' /root/rpmbuild/BUILDROOT/icecast-2.3.2-0.x86_64 '!=' / ']'
+ rm -rf /root/rpmbuild/BUILDROOT/icecast-2.3.2-0.x86_64
+ exit 0
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.yWtx17
+ umask 022
+ cd /root/rpmbuild/BUILD
+ rm -rf icecast-2.3.2
+ exit 0
/bin/find: `/usr/src/redhat': No such file or directory
buildrpm did not create a valid RPM file; check your rpmbuild configuration
Installer exited with error, aborting


there is issues with the v2 DNAS and how it handles the streampath config option in some cases. the usual trigger is not having a / at the start of the entry e.g. having streampath_2=stream2 instead of streampath_2=/stream2 (is something i've internally fixed for when the next public update of the v2 DNAS happens).

it is also likely leading to the other access issues being noted, though if there is only one active stream irrespective of the configuration options then the DNAS can end up trying to provide that as the stream even when it should not (another thing i've hopefully resolved).

-daz

mount points are seted up i CentovaCast Panel but aren't shown in the Shoutcast server as shown in attachments and there is that problem with quality settings (bitrate,encoder etc) which I mentioned in my first post.

Hmmm that's very odd.  Centova Cast reads the mount point information directly from the Shoutcast DNAS configuration file... it doesn't keep a parallel copy of the configuration in the database or anything like that.  So if Centova Cast is displaying both /stream1 and /stream2 in the Centova Cast account editor, then it MUST be getting them from the configuration file... which means ShoutCast DNAS should be able to read them as well.

Could you post (or pm) your ShoutCast DNAS and sc_trans configuration files?  (remove any sensitive info first, like your passwords or IP addresses).  They are stored in /usr/local/centovacast/var/vhosts/USERNAME/etc/ as server.conf and source.conf.

Ihave fixed problem with -lxml2 but I'm still getting this error (it's trying to get to some red had directory but i've got CentOS ?):

Hrmm... either something is not right with your packages, or there's a problem with the IceCast Source RPM from icecast.org.  Under CentOS 6, the rpmbuild utility builds packages under /root/rpmbuild instead of /usr/src/redhat which is probably why /usr/src/redhat doesn't exist.  But the fact that it's failing with an error about /usr/src/redhat means that SOMETHING (either the IceCast SRPM or some part of your build system) is still looking in the old location.

Unfortunately I can't personally do anything about either case, because neither your package configuration nor the official IceCast SRPM is under my control.   What you may be able to do, however, is simply create a symlink from /usr/src/redhat to /root/rpmbuild... eg:

Code: [Select]

ln -s /root/rpmbuild /usr/src/redhat

Then try the IceCast installation again.  That may trick it into using /root/rpmbuild when it looks for /usr/src/redhat.

Icecast is a pain to install -- just had to throw that in!

With this new SHOUTcast 2 what benefits, if any does Icecast have over SHOUTcast?

Another problem is that I can't install IceCast with centova update command

BTW I mentioned in another thread a new feature I added for IceCast installations... running:

Code: [Select]

/usr/local/centovacast/sbin/update --add icecast --icecast-fromsrc
...will try to build IceCast from source instead of using icecast.org's SRPM.  Should work around the issue of their SRPM not working on CentOS 6.

Icecast is a pain to install -- just had to throw that in!

If you're on a Red Hat-based OS that can be true, although there are LOTS of RPMs out there that you can install if you don't want to build from source.

On Debian-based OSes it's a single-command installation: apt-get install icecast2

With this new SHOUTcast 2 what benefits, if any does Icecast have over SHOUTcast?

ShoutCast 2 certainly closes the gap, and the introduction of AAC support will put it above and beyond IceCast for a lot of our clients.  IceCast still does have some substantial benefits though.. off the top of my head, it has much lower memory usage, more mature/feature rich mount point support, scriptable listener authentication support, greater configurability, and, of course, the fact that it's free and open-source.

I take back my comment about Icecast being a pain to install, it still is but not with Centova v3, installation of both Icecast and Ices_cc was a breeze! (as of the latest update this morning 6/27)

As for the mount points, for some reason whenever I create a 2nd mountpoint on SHOUTcast v2 & sc_trans it cause problems, I restart and the entire stream will no longer start, I must change the port # to get the original encoder to even play again and I have never been able to get 2 or more mountpoints to work with SCv2

I also tested the mount points with my Icecast & ices_cc test stream and it worked great, was able to stream @ multiple bitrates with no problems

Also, with Icecast I tested with a live source, all is fine - the question is about the dj manager, I would't think the DJ manager would work with Icecast & ices_cc, is that correct? As with the older Centvoa v2, all the dj's shared the same u/n & p/w, if this is the case and the dj manager does not work with Icecast then could you disable the dj manager url for Icecast streams, the clients would all wonder why the dj manager does not work.

I think that  with SHOUTcastv1 and sc_trans the dj manager could/would work? Could this be yet another option for Centova v3?

And a question about the old SHOUTcast v1, is that going to be history? You have it with the v3 installation docs but I wondered what you recommend, should we just start phasing that out, will SHOUTcast v1 cease to work after a few years or is it going to remain a option? 

mount points are seted up i CentovaCast Panel but aren't shown in the Shoutcast server as shown in attachments

Ahh, my rule has always been to tell clients "check the logs" whenever anything odd happens, and this time I forgot to do that... and it turns out, had you checked your source logs, the error would have been evident.

The next build will have a fix for this issue.  Thanks for the bug report!

The next build will have a fix for this issue.  Thanks for the bug report!

Did You fixed this ?

Because DNAS still can't "see" second mount point from centovacast.
In fact i see you fixed that wierd behaviour with taking bitrate from sekond mount point to main one.

same problem here with mounttpoints,
exactly as described in the first post.
After creating the second mountpoint, it take control of the settings of the first mountpoint (overwrite the bitrate) and is not published at his name:
For example the first is /stream at 128k
the second /stream2  at 64k

The /stream  work at 64k insted 128k, and /stream2 is not present but you can find it in /streamX where X is any number different of 2.
The cc version is the last one.

Just wanted to confirm for you all that I have verified an issue with this, although I can't for the life of me see why it's happening... the configuration files that Centova Cast is now creating after the most recent update appear (to me) to be correct, but sc_trans2 is still having issues with them.

We've just been dealing with another group of issues in another part of Centova Cast this past week, but I intend to get to the bottom of this as early as possible this coming week.  Most likely I'm overlooking something in the fine print in the ShoutCast2/sc_trans2 documentation.

Finally sorted this out.  Oddly enough, you have to actually speicfy both the mount point name (via endpointname_x=/streamx) *and* use streamid_x in the sc_trans2 configuration file... if you omit streamid_x it can't seem to figure it out using the endpointname alone.

A new build fixing this and a few other issues will be up shortly.

Oddly enough, you have to actually speicfy both the mount point name (via endpointname_x=/streamx) *and* use streamid_x in the sc_trans2 configuration file... if you omit streamid_x it can't seem to figure it out using the endpointname alone.

the documentation and example configs do show that it's needed though like is seen in this thread and other places outside of here, a lot of people don't do it. as and when i get new updates of the v2 sc_serv and sc_trans (had already put such changes in the internal builds a few months back), they will be able to work just by looking at the _x part on the config values provided, though it is always best to ensure that things are explicitly noted in the config file.

-daz

Everythink works now !
Thanks for update