chirpradio / chirpradio-archiver Goto Github PK

Writes archive files of CHIRP Radio's live broadcast

License: Apache License 2.0

Go 100.00%

chirpradio-archiver's Introduction

CHIRP Radio is a non-profit organization that runs a community radio station in Chicago focused on new music and the arts.

Get started by reading the development guide.

This is the code for CHIRP's internal web applications. The apps run on Google App Engine, under the 'chirpradio' project. The source code is hosted on Google Code, also under the 'chirpradio' project.

For the chirpradio developer dashboard, go to: http://appengine.google.com/dashboard?&app_id=chirpradio-hrd

For the end-user landing page, go to: http://chirpradio.appspot.com/

For the Google Code project: http://code.google.com/p/chirpradio

Helpful external documentation:

App Engine Python API https://cloud.google.com/appengine/docs/python/?csw=1

Documentation

To read or work on the developer documentation locally, create a virtualenv, and install the requirements:

pip install -r docs/requirements.txt

Run this to build the docs:

make -C docs/ html

Open docs/build/html/index.html in a web browser.

Third party code

google-app-engine-django

Some of the files in this directory and all of files under the appengine_django/ subdirectory are based on rev 81 of the google-app-engine-django Subversion repository.

Django

All files in django.zip are taken from Django 1.0.2-final. It was constructed by running the following commands:

zip -r django.zip django/__init__.py django/bin django/core \
                  django/db django/dispatch django/forms \
                  django/http django/middleware django/shortcuts \
                  django/template django/templatetags \
                  django/test django/utils django/views

zip -r django.zip django/conf -x 'django/conf/locale/*'

These commands were taken from http://code.google.com/appengine/articles/django10_zipimport.html

Some of the CSS files media/common/css are based on files that were copied from django/contrib/admin/media/css.

chirpradio-archiver's People

Watchers

Forkers

kumar303

chirpradio-archiver's Issues

Protect against overwriting existing archive files

This might happen if two archivers were running simultaneously or something weird.

Run from startup script

The archiver should be managed by an Ubuntu startup script of some kind

Add monitoring for when the archiver goes down

It would be nice to send an email (or something) if the archiver panics.

Rotate files better when the system is slow (dropped ticks)

Archive files are rotated at the start of every hour. In the current implementation, if the tick that happens at the top of the hour is dropped (which might happen for slow channel receivers) then the archive file will not get rotated. I've seen this happen while testing on my laptop when the wifi was spotty. I think we could take a new approach more like this:

last_rotation = timestamp
if tick is at the top of the hour or last_rotation > one_hour_ago then rotate the file

Retry harder when there are errors

What I've seen is that when the archiver can't connect to the streaming appliance, it retries but always fails. I think we need to make it retry for longer or possibly introduce a backoff. I think that in most cases the streaming appliance is restarting and taking a while to start up.

Log version of library at startup

It would be nice if the archiver logged the version of the code it's running from when it starts up. This can just be the git revision or whatever makes sense for installing it with go get ....

Always use Chicago time

Force Chicago time so files are always in sync with the broadcast. Right now the code just uses local time. This will run from a server in CHIRP's studio so not a big deal but nice to have.

Add a self-health check

It might be possible to add a periodic task to the ticker that checks the health of the system. Some things that might be interesting to check:

has a file been written lately?
is the currently active file growing in size?
has the broadcast task written bytes to its channel recently?

Fix compatibility with go-logging dependency

The logger looks like it changed upstream. Builds are failing: https://travis-ci.org/chirpradio/chirpradio-archiver/builds/123175053

./archiver.go:272: log.SetLevel undefined (type logging.Logger has no field or method SetLevel)

The last known working version was https://github.com/DramaFever/go-logging/commit/12817945b236e98eda34215d1d6450df6a3d7737

How the heck do you pin Go dependencies to github revisions? :/

Don't write empty files

When the archiver encounters an error that it can't recover from, it writes 0 byte files. This is confusing because at a glance someone might think the archiver is working fine. It shouldn't write files at all.

Clean up all docs about old archiver

Once the new archiver is in production, clean up all the docs on the old archiver to avoid confusion: https://github.com/chirpradio/chirpradio-machine/

Write ID3 tags for the current DJ

It's pretty easy to find out the current DJ using the CHIRP API so the archiver could write ID3 tags for Artist name as the DJ name. This would be nice when DJs are storing their archive files in their own music library. One consideration is that DJs sometimes take a few minutes to update the metadata at the beginning of their own show so this might work best as a post-processing step.

Organize files in date directory

Whoops, the old archiver organized files like:

/archives/2015/10/17/archive.mp3

The new archiver is missing the date part of that directory

Option to quiet down the logging

In order to constantly write a log in production, the logging should be a lot quieter, maybe with -quiet or something.

Archive files sometimes play at the wrong speed

I have seen two reports of this but archive files always play fine in iTunes.

Example:

"iTunes plays the file normally at 1:00:00, as expected. In Windows Explorer, the file specifics indicate that its length is 25:12, not the full hour. In Audacity, the file length is 55:07, and plays sped up to capture that whole hour in the time allotted."

Maybe we need to add file headers specifying the sample rate and other meta info?