[1.14.6] Podcast Apps aren't playing audio

I should mention:

* The site uses CloudFlare for caching, I’ve set it to development mode and purged the cache.
* It uses nginx and I have the recommended configuration for the podcast-download and podcast-player locations.

Same. This is incredibly frustrating. I rolled back to v1.14.3 because it’s the latest version that’s working for me. I’m seriously never updating this again.. I’m probably going to stay on this version for the next few months because I can’t deal with this anymore.

Rolling back to 1.14.3 also made it work for me.

This was driving me crazy too. My download / player links technically work, but they take forever to load. Just like you, rolling back to 1.14.3 made them load immediately. After rolling back, I planned on looking through the github commits one by one to see where this broke, and it turns out the very next commit is what makes this slow. I don’t know why, but perhaps this will help the developer fix it? This is the commit that breaks everything:

https://github.com/hlashbrooke/Seriously-Simple-Podcasting/commit/a035645b74454e299ba5cfbbb2cfb562e9787575

More specifically, if I update to the latest version (1.14.6), commenting out line 935 of class-ssp-frontend.php fixes the download/playback delay. Here is the line:

$size = filesize( get_attached_file( $attachment_id ) );

I’m not sure why, but I’m running nginx / php-fpm.

I’m not sure if this is correct, but changing that line to this seems to be ok:

$size = $this->get_file_size( get_attached_file( $attachment_id ) );

It seems as if the php function “filesize()” is causing the slowdown for me, but using the SSP function get_file_size() seems to be fast. But I’m not sure if these are actually interchangeable.

I am more confused now. It turns out that it doesn’t seem to be those lines that specifically cause the issue. It seems that if $size is non-zero, then the line:

header( "Content-Length: " . $size );

Will cause only Safari to stall (for me). Chrome seems to load instantly. If I comment out that line, or set the Content-Length to 0, Safari also loads instantly.

This might be another clue:

https://feeding.cloud.geek.nz/posts/blocked-queued-connections-keep-alive/

If I change my nginx server config “keepalive_timeout” value, that value is exactly the delay I get, which indicates that the browser is expecting the wrong amount of data based on “Content-Length”, timing out, then continuing? Hopefully these are all clues to help the developer. ??

Now that I think about it – could it be that SSP reports the Content-Length of the podcast file, but since this is a redirect, the browser is expecting the first URL to be that length, eventually timing out, then continuing with the redirect? Should this Content-Length header be set for the redirected URL, not the initial URL?

Ok, going to bed. ??

Thanks for all the input here and sorry for the delay, but this has now been fixed in the latest release (v1.14.7) that will be available in your dashboards within the next hour.

The fixes in this release sort out the file URLs and file loading once and for all, so this kind of issue should not be able to rear its head again.

Thanks for your patience!