I haven’t explicitly tested this plugin with multisite, but I cant see any specific reason why it wouldn’t work. I will be testing that out in the next week or so though.
That being said, I would recommend contacting your host about that to see if there’s anything on their said that they can modify.
Also, as I mentioned in your other support request, you are using the incorrect feed URL – you should be using this one:
http://blogs.magicjudges.org/dwj/feed/podcast
If this has helped you then please consider supporting continued development by leaving a review.
Cheers,
Hugh
> That being said, I would recommend contacting your host about that to see if there’s anything on their said that they can modify.
Well, we’re our own host, so that’s not going to get us anywhere 🙂
I’ve tried using the fixed URL, and the issue persists.
For reference, I believe it’s a relic of the fact that our MultiSite instance uses ms-files.php to serve uploaded files from subsites in the network, and that’s where the byte-range request support gets lost.
I’ll continue to keep looking into this and will report back if I learn anything more. Note that it appears to not be a problem with JUST your plugin, but with podcasting from MultiSite configurations in general. #awkward
OK – in that case I’ll do some thorough testing with multisite and see what I can work out. Will be good to get to the bottom of this so I can say that SSP officially supports multisite 🙂
One thing to keep in mind with your testing:
This might only affect MultiSite installations that were originally created before WordPress 3.5. Before then, MultiSite used a file called ms-files.php to serve subsite files, but I believe that installations since don’t use it. I don’t have any ‘newer’ installations to test on, but I believe newer MultiSites don’t have the issue.
Hi Hugh. Just a follow up to see if you ever found any solutions to the byte-range request issue. We’re having that problem with iTunes and have confirmed that the server is configured correctly. We are using a MultiSite installation (version 4.3.1). Thanks in advance for any advice.
As far as I can tell from my research SSP works just fine with multisite installations. This plugin has no control over the byte-range requests issue as that is completely a server-side problem. This plugin merely sends iTunes to the file, so if your server is not serving the files up correctly then you will need to sort that out with your hosting provider.
There is nothing that I can do from within SSP to fix this issue as the plugin does not have control over the server. If iTunes is giving that error even though you have confirmed that your server is configured correctly then the only reason for that would be that your server is not in fact configured correctly, so you will need to follow up on that.
Sorry that I can’t be of more help, but this is not a plugin issue – it is a server issue.
Cheers,
Hugh
Thanks Hugh. I’ll go back to the host and re-hash this and keep my fingers crossed.
Hi again Hugh. Well, I finally have more information about the byte-range request error. Apologies in advance for the long post.
Short version:
Our paths to the actual mp3 files in the XML are getting redirected. Is this caused by the plugin or WordPress itself?
Long version:
Godaddy ran multiple tests and they said they confirmed that their server supports byte-range requests. So… I asked iTunes support for help and they responded with this:
You can test byte-range requests by looking in the grey box on the right side here:
http://castfeedvalidator.com/?url=http://feeds.feedburner.com/VictoryVida
When iTunes accesses the file:
http://victoryatl.com/victoryvida/podcast-download/4151/yo-creo-en-dios-mi-sanador.mp3
it is redirected to:
http://victoryatl.com/victoryvida/files/2015/10/vida_2015_1018_yo_creo_dios_mi_sanador.mp3
Which does not respond correctly with:
HTTP 206 Partial Content
“Accepts Ranges: Bytes”
Provide the info below to GoDaddy and request they reconfirm.
==== Provide this information to GoDaddy ====
curl -H Range:bytes=50-60 -I -L http://victoryatl.com/victoryvida/files/2015/10/vida_2015_1018_yo_creo_dios_mi_sanador.mp3
HTTP/1.1 200 OK
Date: Tue, 19 Jan 2016 19:20:35 GMT
Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
X-Powered-By: PHP/5.4.33
ETag: “acfd1382d062d2188d0807a096fe7ef6”
Expires: Fri, 22 Mar 2019 05:07:15 GMT
Content-Length: 46386821
Last-Modified: Thu, 22 Oct 2015 12:47:53 GMT
Content-Type: audio/mpeg
=== Example of correct response ===
curl -H Range:bytes=50-60 -I -L http://traffic.libsyn.com/mvclc/2016-01-17_AM_Time_is_a_Treasure.mp3
HTTP/1.1 302 Found
Date: Tue, 19 Jan 2016 20:30:37 GMT
Server: Apache
Location: http://ec.libsyn.com/p/b/a/f/baf03ef280f31882/2016-01-17_AM_Time_is_a_Treasure.mp3?d13a76d516d9dec20c3d276ce028ed5089ab1ce3dae902ea1d06cd8435d2c15c04b2&c_id=10713110
X-Libsyn-Host: traffic4.libsyn.com
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Cache-Control: max-age=2592000
Content-Range: bytes 50-60/15828241
Content-Type: audio/mpeg
Date: Tue, 19 Jan 2016 20:30:37 GMT
Etag: “569adde3-f18511”
Expires: Fri, 19 Feb 2016 00:07:06 GMT
Last-Modified: Sun, 17 Jan 2016 00:18:43 GMT
Server: ECAcc (sjc/4EA8)
Via: 1.1 varnish
X-Cache: HIT
X-Varnish: 1619265824
Content-Length: 11
I forwarded this new info to a tech at Godaddy who responded with this:
Thank you for providing more information on this issue. Using this specific example and command I was able to verify that the server settings are properly working with byte-ranges, however anything going through your WordPress application is not. As a specific example, you can use the exact same referenced MP3 file as a direct link on the server and it works without issue:
$ curl -H Range:bytes=50-60 -I -L http://victoryatl.com/wp-content/blogs.dir/19/files/2015/10/vida_2015_1018_yo_creo_dios_mi_sanador.mp3
HTTP/1.1 206 Partial Content
Date: Thu, 21 Jan 2016 01:20:14 GMT
Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
Last-Modified: Thu, 22 Oct 2015 12:47:53 GMT
ETag: “43a2227-2c3ce85-522b0e74682a0”
Accept-Ranges: bytes
Content-Length: 11
Content-Range: bytes 50-60/46386821
Content-Type: audio/mpeg
The only difference made versus Apple’s example is to use the direct address to the file:
http://victoryatl.com/wp-content/blogs.dir/19/files/2015/10/vida_2015_1018_yo_creo_dios_mi_sanador.mp3
vs
http://victoryatl.com/victoryvida/files/2015/10/vida_2015_1018_yo_creo_dios_mi_sanador.mp3
As this issue is being caused within your WordPress issue, you will need to either find an alternative method of linking or uploading or review this issue with your WordPress developers.
All of this to say that the problem seems to be a redirected path. Not really sure why it’s tagged as a byte-range request error.
Thanks for any info you can provide.
Hi Hugh. Not trying to be a nag 🙂 but was wondering if you’ve had any time to give this some thought?
Thanks a bunch.
I have similar issues with mine where it seems the URL for the audio file is being changed and iTunes doesn’t like it. iTunes is labeling it as a byte-request error but after investigating it, the actual problem is that the link to the audio file is broken. I finally got the error to go away from iTunes by disabling the Seriously Simple Stats plugin but I’m waiting to see if it actually fixed the problem with iTunes (originally iTunes wasn’t showing any of my episodes because it wasn’t seeing an audio file attached.) Is there a way to TURN OFF the URL creation for the audio files and JUST USE THE DIRECT LINK????
Our Podcast feed url is http://www.chapelnext.net/feed/podcast
@cloudfire: There’s no need to shout – you can just use the direct link if you need to do so. This guide in the extensive plugin documentation explains how you can do that: https://www.seriouslysimplepodcasting.com/documentation/podcast-audio-will-not-play-anywhere/ (last section in the guide).
@fuelbox: I honestly cannot work out what the reason is for this issue. The only thing I can think of is for you to use the raw file URL as explained in the guide I linked to here for cloudfire. That will prevent you from being able to use the stats add-on, but it sounds like that might be the only way to get your audio files to work.
To be clear, this is an issue relating to what your server allows in terms of redirects and not something that i inherently wrong inside SSP itself.
