How does 5by5 Time Machine work?

A link generated by 5by5 Time Machine contains the name of a 5by5 show and a number that represents the number of days that should be added to items in the original 5by5 feed for that show. When your podcast client requests the feed, 5by5 Time Machine constructs a feed very similar to that that 5by5.tv offers, but with the dates changed and the original air dates prepended to the episode descriptions. If the altered date for the episode is in the future, it is omitted from the feed.

Why is this useful?

Many users of podcast apps like Downcast and Instacast view their shows in a list of unplayed episodes ordered most recent to least recent. This works well for current shows, but it doesn't work as well if you want to listen to a show again from the beginning, or if you want to start listening to a show that's been airing for a while since the beginning. You could manually go through the list of episodes for that podcast separately, but it's not ideal.

5by5 Time Machine seeks to solve this problem by syndicating old episodes and making them appear as though they're new. For example, if you're a Hypercritical fan, you don't have to give up your weekly dose of Siracusa simply because he's ended the show.

What is 5by5 Time Machine built with?

The domain "5by5timemachine.com" is registered through Hover. The site http://5by5timemachine.com/ is built with and hosted on Squarespace. I used 5by5's offer codes for both services; it seemed only fitting.

As of July 2019, http://5by5timemachine.com/ is built with Jekyll and hosted on Linode. Paying $10/month to Squarespace for 6 years got expensive. Also, I switched over the domain to Namecheap a few years ago when Hover stopped honoring discount codes for domain name renewals.

The http://feeds.5by5timemachine.com/ site is hosted on a Linode VPS. The feed URL is handled with a PHP script that generates the feed on demand from a SQLite database. This database is updated once per hour with a Ruby script I wrote to hit all 5by5's feeds and update the episode information in the database.

The Ruby script does the simplest possible thing that works - it doesn't try to parse the XML of the feed. Instead, it stores the XML wholesale in SQLite blobs. When a feed is requested, the XML blobs for the feed header, footer, and each of the episodes are fetched. The date replacement and description prepend are accomplished with regular expressions. It's incredibly hackish and ugly, but for the moment it works.

Can I use this service with other podcasts?

As I described in the previous section, this service operates basically through regular expression search and replace on the feeds served from 5by5. This works because 5by5's feeds are predictable and consistent. In order to offer this service for general use the parsing of the original feed would need to be much more robust. It's something I'd consider doing if there were demand, but it's not something I'm planning at the moment.