The trinities blog will be unavailable in the middle of the night on this Wednesday-Thursday, USA time. To be more specific, from about 1-5am EST (New York time) on Thursday, January 7.
It is hoped that the upgrade will help with the problems that some podcast listeners have been having with iTunes and iPhones, etc., where episodes only partially download. If you’ve had that problem in the past,
please let me know if you still have it in the coming weeks, staring Jan 11, 2016.
As always, if you have any trouble with your “podcatcher” program, consider using the YouTube playlist (alternate link), which is also always updated on Mondays.
Related posts:
"Trinity" in paperback form
2015: the trinities blog in review
trinities turns 5
update to "Trinity" in the Stanford Encyclopedia of Philosophy
MMM unleashed @ trinities
2015: the trinities podcast in review
Housekeeping: non-serious vs. (merely) non-mainstream commenters
podcast 1 - Introduction
trinities podcast 2023 roundup
Is the God of the Bible the Father alone?
Hi, Dale…
I think the itunes podcast feed is still broken, and I believe it has to do with spaces being in the podcast title. Here’s my symptom: in iTunes, I can see the podcast episodes, but they won’t actually download and instead report “an unknown error occurred (400)”. Well, I looked at the actual network traffic when attempting to download an episode, and it is an HTTP 400 “Bad request” error being returned from the hosting server because the URL that iTunes is attempting to fetch contains spaces. Your feed contains the following url for the most recent episode (not sure if this will render right in disqus comments):
http://media.blubrry.com/trinities/trinities.org/blog/wp-content/podcast/trinities 121 – Do Christians and Muslims worship the same god Part 2.mp3
Unfortunately, URLs can’t contain spaces. The spaces need to be replaced by some other character. Not sure what you’re using to generate the feed… some programs will perform “urlencoding” which replaces spaces or other “illegal” characters with more URL-friendly — if less readable — codes (space becomes “%20”, for example). Or, if you rename the mp3 files to have underscores or something else instead of spaces, the feed URL would probably work.
I’m no expert at podcasting but I’ve managed a church site on wordpress with a podcast feed, so I’ve got a little experience. And I’m pretty competent at networking stuff in general. I’m happy to provide some tech support if you think it would help. Anything for a fellow Texan, even if he did defect.
Hi Ron,
Thanks for the help. I’ve gotten a similar answer elsewhere… Apparently a browser correctly substitutes in a character for the space, which is why all of these work
http://castfeedvalidator.com/?url=https://trinities.org/blog/feed/podcast
And he says that the iTunes app does this as well… but evidently not the store? I don’t think that’s right though…The things is, I’ve been naming episodes like that all along. I just doublechecked, and every single episode has had spaces in the name.
The main things that have changed are switching servers at my webhost (but all the urls remained the same), and switching for one WordPress plugin to another. (Podpress -> Powerpress) This might have somehow changed the way the RSS is written…not sure. I don’t see any options in the plug-in that have to do with spaces…
Someone else suggested that the server change could be the problem – that ever though the urls are the same, the store is looking at the old IP address. I don’t think that’s right either – it’s still getting the RSS feed, and that has the urls – the correct urls (though with spaces) – for the mp3s.
🙁
I don’t think the server change is causing an issue. That all appears to be working fine. The issue arises (as so many do) in a mismatch of assumptions between the podcast client and the plugin generating the feed. (My problem is arising in the iTunes application on my desktop. I download and manage podcasts on my mac, then they get sync’d to my iphone.)
The fundamental reality is that URLs can’t literally contain spaces and certain other reserved characters. If you try to fetch a file from a server using a URL with spaces in it, the server will (should, actually) return an error. The way around this is to replace reserved characters in the URL with placeholders — spaces with “%20”, for example. Now, that replacement can happen at different points in the process. A podcast client may see a URL in a feed that contains spaces, perform the substitution on its end, and use the resulting “encoded” URL to fetch the file — which will work fine. Alternatively, a website feed generator might see a path with spaces, perform the substitution on its end, and put the encoded URL in the feed itself — this will also work fine, since clients can just use the file URL in the feed as-is.
What’s happening in your case is that the Powerpress plugin is not performing the encode when generating the feed. That means clients must perform the encode or the file won’t download. The iTunes desktop client does not perform an encode, and I’m sure there are other clients/apps that don’t also. (The iphone itunes app might… I can’t say.) But for clients that don’t, downloads using the current feed will fail. As it turns out, Blubrry advises against use of spaces in file names.
Using archive.org, I went back in time and pulled a snapshot of your pre-change feed and — sho ’nuff — your old plugin was encoding the file URLs. That was why having spaces in your file names hasn’t been causing trouble before.
Optimally, reserved characters like spaces should be avoided in file names altogether. That sidesteps the whole “who is responsible for encoding” problem completely, and increases the likelihood of compatibility with even the least charitable plugins and clients. Barring that, you might be able to pass an encoded URL to the plugin itself, when you tell it where the file is. To do that, you take the file name (i.e. “trinities 121 – Do Christians and Muslims worship the same god Part 2.mp3”) and run it through an encoder like this one and get the encoded name (i.e. “trinities%20121%20-%20Do%20Christians%20and%20Muslims%20worship%20the%20same%20god%20Part%202.mp3”). Then you use the encoded filename in the URL that you enter in your podcast plugin for the file location (i.e. “http://media.blubrry.com/trinities/trinities.org/blog/wp-content/podcast/trinities%20121%20-%20Do%20Christians%20and%20Muslims%20worship%20the%20same%20god%20Part%202.mp3”). If the podcast plugin can recognize that the URL is encoded and will pass it along into the feed it generates, your clients should get the same sort of URL they were getting with your old plugin. There’s a possibility that the encoding will confuse the plugin, in which case a different approach would be called for…
Comments are closed.