i'm sorry to tell you that after a few months of bug fixing, technical
adjusting and bugging people on the dev list and channel, we decided
Campcaster isn't working for us at Radio Rasia. what we were looking for was
a scheduler that can work with our files - playlists and single files
recordings. (mp3, ogg, m3u) and allow us to open a radio station on a linux
box with a mixer hooked up to a few microphones. this wasn't as easy as it
sounded.
we've ran into many problems, the just of them would be:
- scheduler not stopping promptly, sometimes refusing to stop at all
- can't read single files
- has to be in database and so it was impossible to remove, rename or copy
new files
(each time we had to delete the database and reimport everything from
scratch)
- no easy control over the services
- it didn't play some files
- non-intuitive and complex interface when you just want to put a file or
playlist at a specific time
- works with personal campcaster playlists and not .m3u's or .pls' etc.
- no randomizing
- no generic main playlists
- more, more, more... which our radio maintainer can provide
anyway, it just got to a point we realized Campcaster just may be not for
what we wanted it.
i wrote a 2 perl scripts that combine mplayer and crond together.
it took about a week or two to write, about 200 lines of code, and they work
perfectly.
the benefits of our tailored solution:
1. given a date and time you can put a file (any playable file) or a
playlist (any playable playlist)
2. you can decide on a main playlist to play between all the scheduled ones
3. you can decide on specific main playlists for each day (sunday has its
own playlist and monday uses the main playlist)
4. randomiznig for main playlists automatically
5. the scheduling works without a hitch
6. there is no database and no importing, exporting, rereading, or anything
of that sort
7. the scheduling construct is a text file that can be edited using any
editor
8. the scheduler is run once - and can be run through terminal (don't even
need X for anything)
9. only requirements are crond, perl and mplayer. 2 of which come in every
flavor of *nix and the third is easy to install for anyone.
10. plugins to render more formats are just generally installing them on
your *nix box and mplayer will play them
11. has a year in advanced scheduling option
12. very very very lightweight (very!)
13. easy to update and develop or to write a web interface for
so this is the update on us.
if you want me to send you the perl scripts i'm developing, that could be
arranged.
this isn't a full blown project for now, and it might just stay this way.
we're just developing it for ourselves, really.
good luck with Campcaster where it is found useful (apparently many places,
but not us
While I'm obviously sorry to hear that Campcaster didn't work out for your
station, I think that one of the main reasons for this might be in a very
different use case scenario for your radio, as opposed to other ones. This
is actually emerging as an issue that will have to be addressed by the
Campcaster project - the difference in functionality needs between very
small stations and very large ones. We're already running into that in
several instances, and it may become more of an issue if we start to
attract the interest of both major European broadcasters and more
Internet-only stations.
I'd also like to take this opportunity to ask if you filed tickets for
any/all of the problems you mentioned. I know we worked to address a lot
of your issues - especially in the import script rewrite - we need to get
the other problems assigned tickets, and then to get the tickets actually
fixed.
This goes for anyone who is testing Campcaster as well - we need to get
your bug reports filed as tickets. It's not enough to notice a shortcoming
in the project and then let it go unreported. And while tickets are great,
code commits, patches and constructive solutions are even better.
Best of luck to Radio Rasia,
douglas
=============================================
Media Development Loan Fund
=============================================
Douglas Arellanes
Head of Research and Development
Center for Advanced Media--Prague (CAMP)
Na vinicnich horach 24a/1834, 160 00 Prague 6
Czech Republic
Tel: + 420 2 3333 5356, Fax: +420 2 2431 5419
Mobile: +420 724 073 364 http://www.mdlf-camp.net http://www.campware.org
============================================= http://www.mdlf.org
=============================================
To: "The Campcaster Developers' Mailing List"
cc:
Subject: [campcaster-dev] Update on Radio Rasia and Campcaster
hey Douglas
i'm sorry to tell you that after a few months of bug fixing, technical
adjusting and bugging people on the dev list and channel, we decided
Campcaster isn't working for us at Radio Rasia. what we were looking for
was a scheduler that can work with our files - playlists and single files
recordings. (mp3, ogg, m3u) and allow us to open a radio station on a
linux box with a mixer hooked up to a few microphones. this wasn't as easy
as it sounded.
we've ran into many problems, the just of them would be:
- scheduler not stopping promptly, sometimes refusing to stop at all
- can't read single files
- has to be in database and so it was impossible to remove, rename or copy
new files
(each time we had to delete the database and reimport everything from
scratch)
- no easy control over the services
- it didn't play some files
- non-intuitive and complex interface when you just want to put a file or
playlist at a specific time
- works with personal campcaster playlists and not .m3u's or .pls' etc.
- no randomizing
- no generic main playlists
- more, more, more... which our radio maintainer can provide
anyway, it just got to a point we realized Campcaster just may be not for
what we wanted it.
i wrote a 2 perl scripts that combine mplayer and crond together.
it took about a week or two to write, about 200 lines of code, and they
work perfectly.
the benefits of our tailored solution:
1. given a date and time you can put a file (any playable file) or a
playlist (any playable playlist)
2. you can decide on a main playlist to play between all the scheduled
ones
3. you can decide on specific main playlists for each day (sunday has its
own playlist and monday uses the main playlist)
4. randomiznig for main playlists automatically
5. the scheduling works without a hitch
6. there is no database and no importing, exporting, rereading, or
anything of that sort
7. the scheduling construct is a text file that can be edited using any
editor
8. the scheduler is run once - and can be run through terminal (don't even
need X for anything)
9. only requirements are crond, perl and mplayer. 2 of which come in every
flavor of *nix and the third is easy to install for anyone.
10. plugins to render more formats are just generally installing them on
your *nix box and mplayer will play them
11. has a year in advanced scheduling option
12. very very very lightweight (very!)
13. easy to update and develop or to write a web interface for
so this is the update on us.
if you want me to send you the perl scripts i'm developing, that could be
arranged.
this isn't a full blown project for now, and it might just stay this way.
we're just developing it for ourselves, really.
good luck with Campcaster where it is found useful (apparently many
places, but not us
While I'm obviously sorry to hear that Campcaster didn't work out for your
> station, I think that one of the main reasons for this might be in a very
> different use case scenario for your radio, as opposed to other ones. This
> is actually emerging as an issue that will have to be addressed by the
> Campcaster project - the difference in functionality needs between very
> small stations and very large ones. We're already running into that in
> several instances, and it may become more of an issue if we start to attract
> the interest of both major European broadcasters and more Internet-only
> stations.
i think that was the problem as well. i kept reading on new implementations
of campcaster around the world and it seems like campcaster provides more
than enough for those who need exactly it. i guess we need something else.
I'd also like to take this opportunity to ask if you filed tickets for
> any/all of the problems you mentioned. I know we worked to address a lot of
> your issues - especially in the import script rewrite - we need to get the
> other problems assigned tickets, and then to get the tickets actually fixed.
>
one reason we stayed with campcaster without realizing that this isn't what
we needed, was because of the devotion of the team. it made a very serious
impression on us, that we still recommend others to try out campcaster. from
the start, we wanted to join in the developing effort, but never got around
to it.
This goes for anyone who is testing Campcaster as well - we need to get your
> bug reports filed as tickets. It's not enough to notice a shortcoming in the
> project and then let it go unreported. And while tickets are great, code
> commits, patches and constructive solutions are even better.
actually, we more than slacked off at this. we should have filed more
tickets, we should have updated them and try and write patches for them. we
did neither.
you're absolutely right about that.