My last post was about the
tabcast utility that I had been working on. Well, it's now got a lot of the rough edges smoothed over and is available on RubyGems, so installing it is as easy as gem install tabcast for anyone with gem already installed on their system.
The biggest improvement to date, and the one that has allowed me finally to abandon my trusted and venerable, heavily-modified
bashpodder.sh is the addition of the --killfile option. This option leave out of the output any entries whose {{enclosure_url}} is found in the URL-per-line file specified. There is also a --guidkillfile option if you prefer that, but many of the feeds I consume don't publish guids for every post.
My podcatcher script now is now basically a one-liner, even though there are line breaks in the file for readability:
basedir=$HOME/podcasts
cd $basedir/to_listen
cat $basedir/podcast.conf | while read u; do
/usr/local/bin/tabcast -f "\n" --killfile $basedir/killfile $u
done | while read mp3_url; do
wget "$mp3_url"
echo "$mp3_url" >> $basedir/killfile
done;
podcast.conf contains the list of feed URLs by analogy to bp.conf, which is the equivalent file in the stock bashpodder script. Here, I read each of those feed URLs, call tabcast on each one with the "-f" flag that allows me to specify a format string using Liquid templates. All I'm actually interested in with this script is the URL to the audio file itself, so I use a format string that prints only that, followed by a newline. The "--killfile" option works as I mentioned and weeds out any URLs that I've already downloaded. This is the equivalent of bashpodder's podcast.log file. Then I read this list of audio file URLs, fetch them with wget, and add their URLs to the killfile. My ~/podcasts/to\_listen directory is now brimming over with podcast episodes for me to listen to!
Some easy additions that I'll probably make would be to keep some other pertinent details alongside the mp3s, like the episode and channel titles, on the filesystem alongside the audio files themselves. I'm planning on doing this either by keeping $filename.json files next to them, or by simply writing that info into id3 tags on the mp3 files themselves. Either approach may in fact be a little too high-falutin' for my tastes, though, and a simple directory listing of mp3s suits me just fine at the moment.