Interest Compound Dev Log

Site Differences

Alright, right now, we have a mostly unified configuration system for podcasts in the network. AFAICT, We're all using DropPod now, and we're all on vis.nu somewhere. There are also other similarities1) but that's less important.

Rated80s

Podcasts are served from URLs in the wp-content/podcasts directory. I used to do a bind mount, but that confused backups so I've now set the aliases up in the web server.

Ask an Athiest and the RvM Conglomerate

Thanks to both sites having different servers for podcasts and the website long ago, podcasts are served via urls with subdomains beginning with “media”2). This makes configuration fairly simple.

Both sites are also served via a PHP script that collects stats that are no longer used anywhere worthwhile. Those need to be fixed and turned into something useful in very short order.

Hands Free Football

Podcasts are served from URLS in the episodes directory. Again, much like Rated80s, these are actually stored elsewhere and configured with a bind mount.

2016/06/15 11:43 · sam

Why 31 Days?

Mike asked me to increase the feed window to 31 days, and here's why I was against it:

From a technical standpoint, I'm against it. This may seem kind of nit-picky, but we're in software design territoy here, so nit-picks are a part of the job. If the consensus is that it's necessary to include more than 31 days, I designed it so it can be changed in short order.

First, it's an increase in the amount of bandwidth used just to determine if we have new episodes. The AaA feed size is 19k, by design. The RvM feed is 348k, also by design but for differing reasons. As an external check, the TBTL feed is 200k, which is pretty average for the spot checks I'm doing. Our feed as it stands now is 250k.

While our bandwidth isn't strictly metered as it was in Arizona, there are still drawbacks. As the size of the feed becomes bigger, latency for episode updates becomes longer. More importantly, bigger feeds mean increased data fees for cellular users, as many podcast listeners are.

There's also a potential muddle, depending on how podcatchers are designed. Most catchers just check the feed at arbitrary intervals. However, feeds optionally tell you how often they expect to update, and some podcatchers listen to that figure and act accordingly. Also, some other apps figure out from update history how often to check the feed.

So while your feed is half again as large as the group feed, the IC feed could cost a cellular user *more* money as it has to be checked more often.

A distant second is the increased computational overhead for creating the feed. While it is nowhere near important as the size of the feed, it already takes us up to 30 seconds to generate a copy of the feed when it is not cached.

So, those are the drawbacks. If the benefits surpassed or even matched them, I'd be for increasing the cutoff. They do not appear to be.

While you'd have more than one copy of your integer episodes, they'd be way down the list on a feed with more than one weekly show, where people are less likely to find them. I considered the edge case of someone loading up the feed for the first time, but the issue still applies.

Another stated benefit is having more episodes appear on the iTunes page, but given the increased diversification on podcast technologies in the field– even on the iOS platform– I'd call that a small benefit that isn't worth the drawbacks.

Also, our feed is going to get larger as it as as we add new shows, and we're already going to be adding at least one. If the network grows beyond us, the feed will grow accordingly.

If I thought I could've gotten away with less than 31 days, I would. However, I want to maximize the chance of including an integer and a .5 of RVM. Also in the first meeting, I suggested that if we're going to be a network we should hold ourselves to producing at least once a month. That seemed to go over fairly well, so I used that figure.

This isn't a complex way of saying “No, NEVER!” It's more a brain dump of why I chose what I chose so that you can spot flaws in any of the conclusions I've come to. In fact, I'm glad you asked the question.

Also, the website design takes the differing update schedules of the shows into account, and it should be much less of an issue there.

2016/06/05 03:56 · sam

Version 0 Joint RSS Feed

Attention Conservation Notice: We have a joint RSS feed available here. It works in an interesting way.

I've started on the beginning of the website. Right now, there's no actual content on the site yet, but I have created the IC joint feed.

Background

First, we kind of have to explain what a podcast feed actually is. In short, it is an RSS feed with extensions that contain information about audio files.

So, assuming you don't already know how podcast feeds work, let's quickly unpack that.

  • RSS stands for Really Simple Syndication, and it does exactly what it says. An RSS file is a specially formatted XML file that includes information about a website and content recently posted there.
  • XML stands for eXtensible Markup Language, and is designed as a superset of HTML. Basically, it looks and acts very much like an HTML file, but instead of web documents, it can encode just about any kind of data.
  • The concept of podcasting is a minor extension to the RSS file that provides links to and metadata3) about audio files. They're presented in reverse time order, so more recent is first.
  • In order for these episodes to be available to podcatchers, these RSS files must conform to documented standards.

This file is what constitutes a podcast feed.

The Idea

Since a podcast feed provides a simple and uniform way to figure out what a show is doing, we can use that information to come up with a central store for the network that doesn't require any extra work.

As long as a show has a compliant podcast feed– which is required to be a podcast– I'll have a way to get information about that show on an Interest Compound website, and associated utilities.

Part one is a joint podcast feed: Take all of our feeds, get out the episode information, and collate them into one big list of episodes.

What You Need to Know

There are things you need to know about how it works, so when we launch the site, you are not surprised by how it works.

It Does Not Include Everything

The feed itself orders in reverse chronological order, and goes back an arbitrary number of days. Currently, it is set at 31 days. Episodes older than that are not included in the feed.

Ask an Atheist includes the last 20 episodes, which is something like four to five months. The RVM feed includes the entire site. I don't know what the other shows do. This means that the joint feed only has a subset of what is available on the parent feeds.

It is Not Generated in Real Time

I've added a simple caching system to the feed. As creating the joint feed takes somewhere from 7 to 30 seconds4), I save a copy locally and use that for an arbitrary amount of time. It is currently set to ten minutes.

If you post or delete an episode, it could take up to ten minutes for the IC site to notice. We can increase the amount of time it hangs onto a cached file, but I would be loathe to decrease it.

It Will Change the Name of Your Episode

Given the way most podcatchers work, it might not be immediately clear which episode belongs to which show. Therefore, I've added some intelligence that tacks on the name of the show to the episode title.

One exception: if the title of the show is already in the episode, it won't bother. Specifically, Podcasta La Vista episodes have “Podcasta, La Vista, Baby!” in them, so when it sees that, it won't modify the episode title.

It is Sensitive to Sub-Shows

Radio vs. the Martians and Podcasta La Vista, Baby appear on the same RSS feed. However, I'm pretty sure Mike and Casey would want PLV and RVM shows to have different show names and graphics around them on the website. So, I've added some stuff to detect that.

Right now, it only detects what I'm calling “subfeeds”5) by checking for some sort of fixed pattern on the filename of the audio. So, for PLV shows to be accurately tagged as such, the MP3 file has to begin with “PodcastaLaVistaBaby”.

I chose that because that's what they already do. If we want to change the way it works, we can, but this works out rather well.

Other...

It doesn't know how to handle stuff like joint-episodes. We're a bit away from that right now, so we'll just cross that bridge when we come to it.

It's not well tested yet. This is why I'm handing it to you and not broadcasting it wildly.

OKAY SHUT UP WHERE IS IT ALREADY I MEAN DAMN

It is at this URL.

Complaint about Standards

Herein is a fun lesson in being an internet technologist!

When I said “standards” above, I meant the usual kind of dumb internet standard. In other words, some kind of community consensus is attempted, but it is modulated by major corporations with a stake in the technology trying to fuck with the standard to make it work better for them and worse for everyone else.

The modern podcast standard was most influenced by Apple. If you actually look at a podcast feed, you'll actually see itunes all over the place because that's the namespace Apple used to define their stuff. While podcasting is a bit lucky that this was defined in the era right before Apple went from quirky but democratic to dissociative and fascist, there is a strangeness in the format.

Specifically– and why I'm even bothering with this digression– some of the weirdness is in the explicit tag. Apple isn't really comfortable with a generally “clean” podcast with occasionally “explicit” episodes. It fucks with their content model, so the implementation has a bit of a puritan feel.

As a result, we'll be unlikely to get this feed accepted on Stitcher, Google Play, or iTunes. At least until we manage to make some technical adjustments. Or a better, competing standard comes to dominate.

Caveat 1: Note I'm saying technological adjustments, not production adjustments. I'm not talking about censorship. Fuck censorship in the ear. I want a podcast network where I could produce an episode, e. e. cummings-esque, entirely composed of curses.

Sub-caveat 1a: I'm not kidding. I once gave a speech entirely composed of the word “dogfucker.”

Caveat 2: On my own, I would not actually submit this feed to anything. While I imagine it'll be useful for us and some people who actually want to follow all of our shows– there's a few of those– it's more for collecting data about the network. However, this isn't on my own, so I'll leave that to our own corporation-deficient consensus.

2016/06/03 03:12 · sam
1)
everyone WP, everyone Bluberry
2)
i.e. media.askanatheist.tv and media.radiovsthemartians.com
3)
type of file, size, runtime, explicit flags, that sort of thing
4)
the app has to connect to each website in the network and processs the RSS output before it can create its own output
5)
rather inaccurately