[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 Smile

    good day,
    sawyer/Radio Rasia.
  • 2 Comments sorted by
  • Hi Sawyer,



    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
    =============================================




    "sawyer x"
    Sent by: campcaster-dev-bounces@netfinity-4.mdlf.org
    06/18/2007 12:08 PM
    Please respond to "The Campcaster Developers' Mailing List"


    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 Smile

    good day,
    sawyer/Radio Rasia.
  • Hey

    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.