[Icecast-dev] Javascript source client

[Alexandru Ardelean]

This is turning a bit into a hate-thread against Airtime.
Personally, I am not much of a hater (although sometimes I make exceptions,
depending on how my day is), but I will say that Airtime is a
pain-to-maintain on your server.

It's pretty bloated as well; correct me if I'm wrong (this dates back to
when I tried it with version 1.5 and 1.6 and 2.0 was in the works)
- Zend PHP framework (bundledinto the app) + plenty of JavaScript thrown in
- RabittMQ for queue-ing messages to liquidsoap
- liquidsoap pushing to icecast
- icecast
- Python glue-code that had UTF-8 problems with certain non-ASCII filenames
(mostly because of Python 2.6-7 which is not yet UTF-8 compliant)
- monit  to keep the whole thing from cracking
- PostgreSQL, which is less friendly than

all of this to add a simple (and (back then) not very useful) frontend to
make a playlist; and when you try to upgrade, a lot of the problems you've
hacked into Airtime to get it working, get reset, so you have to start
re-hacking it; that is, if it still works after upgrading it;
Other problems that I've had with Airtime were:
- empty streams; just silence, because...... RabbitMQ I guess
- the UI said the radio was on-air, but everything in the back was just
sitting
- sync-ing into the DB always failed when I had non-ASCII filenames (bad
Python scripting); I had impartial files in Airtime because of  that;
- if you had a podcast of 1h and 10-30 seconds, you could only set it to
the 1h + 1minute, or cut it 1h sharp; kind of... well, I didn't like it,
personally;

I think (and it's a bit evil of me to say this without having contributed
to Airtime) that it should have only consisted of any of these (or similar)
combinations:
- (standard) PHP + icecast
- a simple frontend in whatever(for liquidsoap) + liquidsoap + icecast
- icecast + frontend written for icecast (i saw someone work on this, where
)
- Python (frontend + queue-ing to icecast) + icecast

Queue-ing is a bit redundant with IceCast, if you try to use one server as
master, and others as slaves or relays.
You'll still need a load balancer for this, but that's another topic.

In the end, I found that using just liquidsoap + icecast (and shoutcast
because I wanted to listing in the Shoutcast Directory) was more than
sufficient for my needs.
And after that a simple frontend with HTML5 was sufficient to be the player.

I personally still think that if you want to do radio-streaming on the net,
you have to start working from the last node that sends out every byte on
the web (icecast and shoutcast in this case) and work backwards from there.




On Mon, Jun 17, 2013 at 1:14 PM, macbroadcast <marc at let.de> wrote:

> Am 17.06.2013 11:12, schrieb Daniel James:
> > Airtime
>
>
> After several weeks of trying and calling my provider and talked to your
> support i gave up on
> airtime, because it does not work on a virtualized system, it seems the
> installtion script has
> dependencies.
>
>
> http://forum.sourcefabric.org/discussion/15323/airtime-install-on-ubuntu-error-in-installation-script
>
>
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/icecast-dev/attachments/20130617/f6df79ec/attachment.htm