Most recent episodes showing 1.0bytes filesize in RSS meta

Does it help to delete the content of the “File Size:” input field in “Podcast Episode Details” and then Update? It should take the correct file size then.

Thanks, I tried that. It’s not adding anything in the file size field on upload. I added it manually, refreshed RSS and it still showed (MP3 Format Sound, 1.0 bytes) in the RSS feed

I’ve never had an issue with the filesize not being saved like that. Is it affecting your feed subscribers or iTunes or anything like that? Or is it merely the fact that it shouldn’t be doing it?

With regards to the Date Recorded feature – that has been brought to my attention already and it will be fixed in the next bug fix release within the next few days ??

Some mobile podcast apps such as Stitcher and some others that users have contacted me about, do not show any episodes passed the last one with a correct filesize. Like it can’t parse past the 1.0 bytes size for the audio enclosure. Stitcher support finally got back to me and the can’t process it with the 1b filesize. If you play the audio directly from the RSS or website, they play fine.
It’s just reporting a null filesize in RSS feed.
I’m really lost.
RSS: https://feeds.feedburner.com/UnityOfPalmHarborPodcast
URL: https://unityofpalmharbor.org/series/sunday-talks/

If the audio file size cannot be calculated then the feed uses 1 byte as the size purely because a value of 0 would invalidate the feed. So the problem here is that the plugin is unable to determine the size of your audio files. I had a look at your feed and the file URLs you are using and the only issue I can see that might be causing a problem here is that your audio files have periods (.) in the file names. That can cause problems with this sort of thing as it confuses the algorithms that do the file size checks.

With that in mind a possible solution for you would be to rename your audio files so you strip out the periods, or replace them with something else (like dashes) and then edit the audio file URL field in your podcast episode to reflect the new file name. I’m fairly certain that will fix things for you, but I can’t be 100% sure.

One caveat – do not replace the periods with spaces as spaces can often cause problems – it’s much better to use hyphens or underscores.

Let me know if it works!

Hmm… The most recent files that have the issue have no periods in the filenames. Just a few hyphens.
Looked at the two offenders in itunes and it displays a file size of 1kb for the two files affected. My work flow from capture to upload has not changed.
I’ll try some different steps I guess :-/

If your recent files are much larger than your previous ones then that could be the cause as the header request for the files could be timing out before the file size has been retrieved.

The file size check is set to timeout after 10 seconds, as I did not want to kill page load times purely for file size checks. The best way to test to see if this is the problem is by altering the HTTP timeout value dynamically, which you can do with a handy snippet:

add_filter( 'http_request_timeout', 'edholtzman_ssp_http_request_timeout', 10, 1 );
function edholtzman_ssp_http_request_timeout ( $timeout ) {
  return 20;
}

That will set the timeout delay to 20 seconds, but you can make it whatever you like (bearing in mind that your server will have its own request timeout limit that you won’t be able to go over).

Add that snippet to your theme’s functions.php file and see if it makes a difference by leaving the file size field blank for your episode and hitting the update button. If it works then the file size fields will be populated and your feed will now contain the byte value of the file size.

Man, I’m at my wits end with this.
I added the snippet to my functions.
I went back and re created/encoded and named an episode from scratch.
https://unityofpalmharbor.org/podcast/20151018-yes-and-no/
I still get the (MP3 Format Sound, 1.0 bytes) in my RSS.

Here’s the direct MP3 for what it’s worth…
https://unityofpalmharbor.org/wp-content/uploads/2015-10-18-yes-and-no.mp3

also, interestingly, after the latest update the ‘date recorded’ date picker still ends up blank after setting the date and updating.
I’ll be over here banging my head.

Hmm – if the Date Recorded field is still blank after saving (I assume you’ve updated to v1.13.2 as it contains a fix for that field) then it sounds like something is interrupting the saving of your episode meta fields. My guess is that the file size check is timing out and then breaking the saving process for all the subsequent fields.

Try updating that snippet I gave you to set the timeout to an unnecessarily large number like 200 seconds:

add_filter( 'http_request_timeout', 'edholtzman_ssp_http_request_timeout', 10, 1 );
function edholtzman_ssp_http_request_timeout ( $timeout ) {
  return 200;
}

Add that to your functions.php file and then click the update button on your episode (making sure that the file size field is blank before you click update).

If it still doesn’t work then it’s likely that your server is blocking requests from the WordPress HTTP API functions (in this case it’s using wp_remote_head()) and you will need to get in touch with your hosting provider about that.