This is a small, very work-in-progress app to save off what's playing on radio stations to Elasticsearch.

Earlier in its life (see the first commit), it started as a more ambitious project to save to a SQL database and build out a web UI; this turned out to be overkill, as Kibana is much more than capable of doing the same, with less work. Thus the project migrated to bash and Elasticsearch.

Two Web sources are currently supported, depending on what your local radio stations support: TuneGenie and Triton Digital.

The tools jq and XMLStarlet are required for parsing. curl is required for writing to Elasticsearch. These are available in just about all environments via package managers.

Daemonize the included shell scripts using your favorite method - systemd, Docker containers, or otherwise. An example systemd unit file is provided as a convenience.

These environment variables must be set:

• ES_URL to the Elasticsearch index address, e.g. http://localhost:9200/radio
• STATION_NAME to the station name, e.g. WERS
• STATION_PROVIDER to the provider name, either tunegenie or tritondigital.

In general, finding the right script to use, and the right parameters, is a matter of loading your favorite radio station with your browser's dev tools open.

TuneGenie's API endpoints speak JSON. The API itself appears to be consistent across stations; only the DNS name changes.

Confusingly, the API requires authentication to use:

$ curl http://wers.tunegenie.com/api/v1/brand/nowplaying/
{"meta": {"status": 401, "error": "Authentication Required"}}

Giving it an expected authentication header is sufficient to "authenticate":

pi@raspberrypi:/usr/local/bin $ curl -s -H "Referer: http://wers.tunegenie.com/onair/" http://wers.tunegenie.com/api/v1/brand/nowplaying/ | jq .
{
  "meta": {
    "status": 200,
    "base_url": "http://wers.tunegenie.com"
  },
  "response": [
    {
      "artistlink": "/music/red-hot-chili-peppers/",
      "sid": 450747628,
      "played_at_display": "6:14 PM",
      "sslg": "look-around",
      "songlink": "/music/red-hot-chili-peppers/_/look-around/",
      "concertslink": "/music/red-hot-chili-peppers/_concerts/",
      "played_at": "2022-01-08T18:14:29-05:00",
      "albumslink": "/music/red-hot-chili-peppers/_albums/",
      "artist": "Red Hot Chili Peppers",
      "song": "Look Around",
      "videolink": "/music/red-hot-chili-peppers/_/look-around/_video/",
      "aslg": "red-hot-chili-peppers",
      "lyriclink": "/music/red-hot-chili-peppers/_/look-around/_lyric/",
      "campaignlink": "/contest/red-hot-chili-peppers/",
      "topttrackslink": "/music/red-hot-chili-peppers/_toptracks/"
    }
  ]
}

Triton Digital's API speaks XML:

$ curl -s 'https://np.tritondigital.com/public/nowplaying?mountName=WBOSFMAAC&numberToFetch=1' | xmlstarlet fo
<?xml version="1.0" encoding="UTF-8"?>
<nowplaying-info-list>
  <nowplaying-info mountName="WBOSFMAAC" timestamp="1641683906" type="track">
    <property name="cue_time_start"><![CDATA[1641683906920]]></property>
    <property name="cue_title"><![CDATA[What Ive Done]]></property>
    <property name="track_artist_name"><![CDATA[Linkin Park]]></property>
  </nowplaying-info>
</nowplaying-info-list>

The default numberToFetch appears to be the last six entries; we specify numberToFetch to limit to the one we care about. There is additionally an eventType=track provider specified on all URLs I've found, but I haven't found its purpose. There also appears to be cache-busting parameter, request.preventCache=(UNIX timestamp), that likewise seems to have no purpose.