Attemping to install Centova Cast V3Beta with icecast and ices2 using the following:

wget -O install.sh install.centova.com/my key goes here and is working

chmod a+x ./install.sh

./install.sh --channel=unstable  --icecast --icescc --force

This is on a new Servint VPS running the following:

The operating system is CentOS 6 - i386 (32-bit)
Apache version    2.2.22
PHP version    5.2.17
MySQL version    5.1.63-cll
Architecture    i686

Note sure what other relevant info I should provide?

When trying to install as above I end up with the following error that halts the install:


Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.0Y6NlQ
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd icecast-2.3.2
+ '[' /root/rpmbuild/BUILDROOT/icecast-2.3.2-0.i386 '!=' / ']'
+ rm -rf /root/rpmbuild/BUILDROOT/icecast-2.3.2-0.i386
+ exit 0
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.RHw9yx
+ umask 022
+ cd /root/rpmbuild/BUILD
+ rm -rf icecast-2.3.2
+ exit 0
buildrpm did not create a valid RPM file; check your rpmbuild configuration
Installer exited with error, aborting
Installer exited with error, aborting

NOTE: Can provide more logs if they would prove helpful?

So my questions are:

1) Anyone see anything in the specs I listed that would be a red flag?

2) Any resource I can read on how to go about starting to resolve the above error?

I have read through the forums, documentation, and knowledge base articles but cannot seem to find a way to get past this error.

I was able to get shoutcast/sctrans v2 installed but really would prefer to run icecast.

Thanks!
~John

You didn't include the actual error messages from rpmbuild in your post so it's hard to say for sure.   But another user did report a problem trying to build the IceCast SRPM distributed by icecast.org on CentOS 6.  And Centova Cast's installer does use that SRPM.

You might want to try out an experimental feature I added in the latest CC build... specify --icecast-fromsrc on the install.sh commandline to try to build IceCast from the official source tarball instead of the SRPM.  It's untested aside from on my dev machines so YMMV, but it may solve your issue.

I was able to do a quick test install before you took things offline to work out that php 5.4 issue and I can tell you that using the following did complete without issue.

./install.sh --channel=unstable  --icecast-fromsrc --icescc --force

Looking forward to trying a clean install later today when everything is back online.

Thanks again for the quick response and sorry for not including relevant details in my initial post.......still learning all this linux stuff!

John

Getting much closer!

Took about 15 minutes this morning and I had everything installed and running and can listen to my stream! Thanks!!

May have a cron issue to track down ans I do not see stats updating and all recent tracks are showing as 'Unknow'.

Thanks again for the help in getting this running!

John

Yes I have cron issues also, I think a couple weeks ago I ran crontab -e and saw about 10 different cronjobs, however now I do not see any. I noticed this after I restarted yesterday, I had hoped the upgrade today would put the cront jobs back but they are still missing

I do have one I added by hand it runs every 30 min which can cause problems for uploads but it is a quick fix

0,30 * * * * /etc/init.d/centovacast restart

Running crontab -e just edits the root user's crontab - you won't (ever) see the Centova Cast cron job there.

O ok, I had assumed I could view all cron jobs as root, that kinda explains a lot,  I have also checked all the cron folders and file(s) in the /etc/ folder but could not find anything with centova in them. It seems if I do not run the cron I made I have problems, even still that does not seem to update everything, the disk space used to work and still has older data but no disk usage, no bandwidth stats, stats say it has been 874 peak listeners and it never came close to that, all this after a reboot yesterday.

Does /etc/cron.d/centovacast exist?  And are any issues being reported in your cron logs (Centova Cast-related or otherwise)?

Ahh there they are I think I kinda see what my issue is, on my ADMIN dashboard the disk quota for each stream is correct

djfreeze   8184  ShoutCast2   100   128 kbps   0 MB (UNL)  2.6/4.9G   

but when I login to the account, the same one shows

Disk usage: 10/5000MB

Plus my bandwidth stats all are at 0, these are the reasons I did not think the cron's were running, but I have verified they are I ran TOP and saw them run so I am not sure why they do not show


I also have a 2nd test server with the same types of issues, no bandwidth stats and different disk usage stats

Still having a number of issues but at least I got to the point where the stream plays.


Current Listeners - Updates Correctly
Data Transfer - always 0B
Disk Usage - always 0B

Upper left of screen when logged in as a client.

Now playing - always blank
Stream name - always blank

General Overview > Recent Tracks > Always shows unknown

Stream is playing correctly and I can listen to it but the start page has issues also.

No Album/Song title data showing.

stream name not displayed.

At this point I am thinking it may just be easier to blow this whole install away and start over!

Gave up on using servint as a host and went back to hostgator. Nor matter what I tried to run on servint I could never get anything to work.

So now I am back to running icescast/ices-cc on hostgator and while the install went fine and the stream play I again have no stream name, track names, etc. everything shows as unknown.

No clue how the first night I signed up I had this running on hostgator and everything was fine and now no matter what there always seems to be an issue.

Thinking this is all beyond my tech abilities and will just use Live365 for my station. Will keep an eye on the site here and see what happens once 3.,0 is out of beta and fully documented with more users. Love the control CC gives me but am just not able to fully make it work.

Code: [Select]

Thinking this is all beyond my tech abilities and will just use Live365 for my station.Certainly your choice, but bear in mind that this is a beta you're participating in so any issues you're experiencing are either 1) the result of a damaged installation caused by a past (now-fixed) bug, and just requires a reinstallation, 2) a bug in the current version you're using that hasn't been fixed yet, or 3) expected behavior that's just not well-documented because the formal documentation is not yet released.

So you can't really take personal responsibility for the issues you encounter in v3.   Encountering bugs is, of course, the purpose of a beta -- we do it now so that these issues don't show up in production.

As for this "Unknown" track title issue, I don't recall if you were the first to report it or just one of the many who did, but this ending up being a critical issue and the efforts (and/or suffering ) of yourself and everyone else who submitted info about it were greatly appreciated here.

It was VERY tricky to track down... I spent many 10-hour days this past week trying to figure it out.  In the end, it ended up being a bloody PHP bug of some sort.  For those interested in the technical details: If ices made an HTTP request to Centova Cast to fetch the next song's info, and that happened to occur while another HTTP request was being made to the Centova Cast web interface, PHP would in some cases close its FastCGI connection to nginx with nothing but an "HTTP/1.1 200 OK".  Both script instances would run to completion without error, but one would generate no output beyond its headers, and nginx would record a "connection reset by peer" while reading from the upstream FastCGI server.  Nothing in the PHP error logs, and no combination of output buffering settings (including disabling it completely) had any impact.  This caused ices to fail over to its static fallback playlist, and for some reason (which I haven't determined yet) it used the blank artist name/song title from the previous, failed request.

The biggest problem was that it didn't occur on our dev servers for the longest time, so I couldn't reproduce it.  It wasn't until we upgraded our dev servers to the new PHP v5.4-based release that it started happening here.

Switching to php-fpm eliminated this issue entirely, so while I don't know exactly what triggered this issue, there's clearly something dodgy in the classic PHP FastCGI interface in recent PHP versions.

I'll be pushing out a new php-fpm-based build shortly, and it works very nicely.

Ran the updater this morning, no errors encountered.

Re-started cc and now when going to my admin login page or stream page I get a white screen with just the following: 

_il_exec failed

More than happy to provide access to my server if you think it would help diagnose.

I think it's release bug. I have the same problem
So we waiting ...

Latest build seems to have installed fine ans so far stream name and song title appear to be being displayed correctly everywhere.

Thanks!