I've got the latest stable version of Icecast installed on a CentOS 5.* server without an issue during the installation.
Every 10-12 hours icecast is stopped responding and need to start server manually via the Centova cast interface.
If IceCast stops responding (i.e., it actually freezes up) then something is almost certainly wrong with your IceCast build... there's really nothing in Centova Cast (which is an entirely separate and self-contained application) that could cause your IceCast process to freeze up.
I can't figure out anything from centova logs
You won't find anything about IceCast in the Centova Cast logs... you'll want to look in your IceCast logs, although if IceCast is actually freezing you may or may not find much of interest there.
and their support answered in my question that icecast is very buggy and they do not support it.
Hopefully that first bit is not exactly what was said -- IceCast is probably the least buggy streaming server out there.
We also used to have problem with IceCast a few years ago, stream would stop for no reason --it turned out to happen only on the streams with over 5GIG of mp3's, the server was not fast enough to scan the database for new songs
This will cause the autoDJ to stop, but it won't cause IceCast to stop responding or freeze.
Also to be clear, the problem My AutoDJ described is more about the quantity of MP3s than their size. If you have five 1GB MP3s it's not going to be a problem at all... whereas if you have 5000 1MB MP3s, your MySQL server needs enough CPU resources to be able to process all 5000 of them, figure out (and exclude) the ones have played in the past few hours, then apply the playlist scheduling criteria to select a track from the remaining MP3s. All of that needs to take place in under a second or so, so that the name of the next track is available by the time the current song ends. And the server needs to be powerful enough that MySQL can do it without hogging so much CPU time that the icecast process gets starved. If any of that fails, the autoDJ is going to either start stuttering, or stall out completely.
On most modern servers it's not usually an issue, and you don't usually need "big iron" to accomplish it... but if your server is already under load and/or under-spec'd, and you add a few huge stations to it, it may become a problem. And it may only be intermittent, i.e., things may work fine until, by random chance, three big stations happen to have songs end at the same time. If CC queries MySQL for all 3 stations' next songs simultaneously, and MySQL doesn't have enough CPU resources to return them all in a timely manner, the autoDJs will choke.