M4A can not be downloaded in some clients

I just published a new episode. Some users report problems downloading the m4a file. Current reports are PocketsCasts on Android and Instacast on iOS. Both m4a feed. Only the new episode can not be downloaded. Older episodes work fine.

On feed reloead one user even gets this:

I only have an iOS device. Can not reproduce the problem. Works for me in Instacast, PocketCasts and Podcasts App.

I can not see what the problem is. Can download the file on all my devices. The tracking redirect works fine (for me). The feed validates. All asset files are present and reachable.

I asked my listeners to resubscribe. Did not solve the problem.

Website             http://podcast.funkenstrahlen.de
PHP Version         5.6.6
WordPress Version   4.2.2
Publisher Version   2.2.0
Web Player Version  2.0.17
Twig Version        1.18.1
open_basedir        ok
curl Version        7.19.7
iconv               available
simplexml           ok
max_execution_time  30
upload_max_filesize 290M
memory_limit        256M
disable_classes     
disable_functions   
permalinks          ok (/%year%/%monthnum%/%day%/%postname%/)
podlove_permalinks  ok
podcast_settings    ok
web_player          ok
podlove_cache       on
assets              
	mp3    audio/mpeg
	m4a    audio/mp4
	opus   audio/ogg;codecs=opus
	psc    application/xml
	png    image/png
	flac   audio/flac

0 errors
0 notices
Nice, Everything looks fine!

Feed entry from http://podcast.funkenstrahlen.de/feed/m4a

<item>
<title>FS065 – HTTPS für Podcasts</title>
<link>
http://podcast.funkenstrahlen.de/2015/05/28/fs065-https-fuer-podcasts/
</link>
<pubDate>Thu, 28 May 2015 16:02:03 +0000</pubDate>
<guid isPermaLink="false">podlove-2015-05-28t10:42:08+00:00-2d26548d93fb6d0</guid>
<description>
<![CDATA[
Vor ein paar Wochen habe ich euch freudig davon berichtet, dass ich den Podcast auf HTTPS umgestellt habe. Das hat jedoch einige Probleme verursacht. Unter anderem war der Podcast nicht mehr bei iTunes zu finden.
 
 In dieser Folge spreche ich mit Henning Krause. Er hat sich im Rahmen des Resonator Podcasts schon einmal mit all den Schwierigkeiten auseinandergesetzt, die auftreten wenn man einen Podcast via HTTPS anbieten möchte.
 
 Wir erzählen was unsere Erfahrungen sind und welche Probleme auftreten. Am Ende müssen wir feststellen, dass die Zukunft leider noch auf sich warten lässt.
]]>
</description>
<atom:link rel="payment" title="Flattr this!" href="https://flattr.com/submit/auto?user_id=i42n&popout=1&url=http%3A%2F%2Fpodcast.funkenstrahlen.de%2F2015%2F05%2F28%2Ffs065-https-fuer-podcasts%2F&language=de_DE&category=audio&title=FS065+%26%238211%3B+HTTPS+f%C3%BCr+Podcasts&description=Vor+ein+paar+Wochen%C2%A0habe+ich+euch+freudig+davon+berichtet%2C+dass+ich+den+Podcast+auf+HTTPS+umgestellt+habe.%C2%A0Das+hat+jedoch+einige+Probleme+verursacht.+Unter+anderem+war+der+Podcast+nicht+mehr+bei...&tags=Apple%2CEmpfehlung%2CHenning+Krause%2Chttps%2CiTunes%2CPodcast%2CPodcaster%2CProbleme%2CSSL%2CWordpress%2Cblog%2C+podcast" type="text/html"/>
<psc:chapters xmlns:psc="http://podlove.org/simple-chapters" version="1.2">
<psc:chapter start="00:00:38.493" title="Henning Krause"/>
<psc:chapter start="00:03:28.257" title="HTTPS für Podcasts"/>
</psc:chapters>
<atom:link rel="http://podlove.org/deep-link" href="http://podcast.funkenstrahlen.de/2015/05/28/fs065-https-fuer-podcasts/#"/>
<enclosure url="http://podcast.funkenstrahlen.de/podlove/file/761/s/feed/c/m4a/fs065-https-fuer-podcasts.m4a" length="28733781" type="audio/mp4"/>
<itunes:duration>00:27:59</itunes:duration>
<itunes:author>Stefan Trauth</itunes:author>
<itunes:subtitle>
Ein Gespräch mit Henning Krause über HTTPS für Podcasts: Warum das Sinn macht und wo es noch Probleme gibt.
</itunes:subtitle>
<itunes:summary>
Vor ein paar Wochen habe ich euch freudig davon berichtet, dass ich den Podcast auf HTTPS umgestellt habe. Das hat jedoch einige Probleme verursacht. Unter anderem war der Podcast nicht mehr bei iTunes zu finden. In dieser Folge spreche ich mit Henning Krause. Er hat sich im Rahmen des Resonator Podcasts schon einmal mit all den Schwierigkeiten auseinandergesetzt, die auftreten wenn man einen Podcast via HTTPS anbieten möchte. Wir erzählen was unsere Erfahrungen sind und welche Probleme auftreten. Am Ende müssen wir feststellen, dass die Zukunft leider noch auf sich warten lässt.
</itunes:summary>
<itunes:image href="http://podcast.funkenstrahlen.de/wp-content/cache/podlove/50/e89a5d80b2e54bac987130902571c6/fs065-https-fuer-podcasts_original.png"/>
<content:encoded>
<![CDATA[
<p>Vor ein paar Wochen <a href="http://podcast.funkenstrahlen.de/2015/04/11/fs062-die-podcast-suchmaschine/">habe ich euch freudig davon berichtet, dass ich den Podcast auf HTTPS umgestellt habe.</a> Das hat jedoch einige Probleme verursacht. Unter anderem war der Podcast nicht mehr bei iTunes zu finden.</p> <p>In dieser Folge spreche ich mit Henning Krause. Er hat sich im Rahmen des <a href="https://resonator-podcast.de/">Resonator Podcasts</a> schon einmal mit all den Schwierigkeiten auseinandergesetzt, die auftreten wenn man einen Podcast via HTTPS anbieten möchte.</p> <p>Wir erzählen was unsere Erfahrungen sind und welche Probleme auftreten. Am Ende müssen wir feststellen, dass die Zukunft leider noch auf sich warten lässt.</p> <h4>Links</h4> <ul> <li><a href="https://resonator-podcast.de/">Resonator Podcast</a></li> <li><a href="http://raumzeit-podcast.de/">Raumzeit Podcast</a></li> <li><a href="http://henningkrause.com/">Henning Krause</a></li> <li><a href="https://www.ssllabs.com/ssltest/">SSL Labs zum Testen</a></li> <li><a href="https://www.startssl.com/">StartSSL</a></li> <li><a href="https://funkenstrahlen.de/blog/2015/03/20/tls-angeknipst/">TLS angeknipst – Blogpost auf Funkenstrahlen</a></li> <li><a href="https://sendegate.de/t/ppw15a-doku-https/1341">Diskussion zu HTTPS im Sendegate Forum</a></li> </ul> <p>Das Intro, Outro und die Thementrenner stammen von N’Surgent von <a href="http://www.jamendo.com/de/artist/429942/rapture">Rapture auf Jamendo</a>. Es steht unter einer <a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Licence</a>.</p> <p>Alle verwendeten Fotos stammen von pixabay.com und stehen unter einer <a href="https://creativecommons.org/publicdomain/zero/1.0/deed.en">Creative Commons CC0 Lizenz</a>.</p><p><a href="http://podcast.funkenstrahlen.de/?flattrss_redirect&amp;id=980&amp;md5=d373913f3a96c5764e0d9bd2ff710426"><img src="http://podcast.funkenstrahlen.de/wp-content/plugins/flattr/img/flattr-badge-white.png" srcset="http://podcast.funkenstrahlen.de/wp-content/plugins/flattr/img/flattr-badge-white.png, http://podcast.funkenstrahlen.de/wp-content/plugins/flattr/img/flattr-badge-white@2x.png 2xhttp://podcast.funkenstrahlen.de/wp-content/plugins/flattr/img/flattr-badge-white.png, http://podcast.funkenstrahlen.de/wp-content/plugins/flattr/img/flattr-badge-white@3x.png 3x" alt="Flattr this!"/></a></p>
]]>
</content:encoded>
</item>

I think about disabling the tracking feature, but I fear bad consequences: [solved] What happens when Tracking is disabled?

Any ideas on how to debug this further?

Maybe my redirects are the problem?

Old Feed was at http://podcast.funkenstrahlen.de/fs/mp3

Some time ago I redirected all Clients (temp) to https://podcast.funkenstrahlen.de/fs/mp3. However I removed this redirect > 1week ago. Maybe the clients sill use the https feed (its still available) and can now not do the http redirect because of the tracking?

How can I redirect all https feed users to the http feed?

The normal podcast feed seems to be just fine.

To redirect the old https feed to the new feed point to the absolute URL (including the “http://” at the beginning). Currently the old feed is simply redirected to “/feed/mp3” which might be misunderstood by some clients.

So 3 redirects for each asset slug?

https://podcast.funkenstrahlen.de/fs/mp3 => http://podcast.funkenstrahlen.de/feed/mp3
http://podcast.funkenstrahlen.de/fs/mp3 => http://podcast.funkenstrahlen.de/feed/mp3
https://podcast.funkenstrahlen.de/feed/mp3 => http://podcast.funkenstrahlen.de/feed/mp3

If I now try to access https://podcast.funkenstrahlen.de/fs/mp3 via Chrome:

The last rule is the problem. https://podcast.funkenstrahlen.de/feed/mp3 => http://podcast.funkenstrahlen.de/feed/mp3 It creates the loop. How can I set a rule like this without creating a loop?

I think the feed reload fail in Instacast (might be the redirect problem) and the download failure of the m4a file might be two different problems actually.

Right now I can not check if the new redirects solved the Instacast feed problem. But I think this was the problem because resubscribing helped the listener with the problem.

The loop is caused by the web server already doing a https to http redirect internally based on the web server configuration. so Podlove never sees https URLs I guess. if you leave rule 3 out is there anything missing?

Why do you think the Webserver already does https->http automatically? I do not think so.

If I access https://podcast.funkenstrahlen.de/feed/mp3 I get the feed via https. I want https to be available for wordpress login. However I would like to redirect all users who subscribed to https://podcast.funkenstrahlen.de/feed/mp3 to http://podcast.funkenstrahlen.de/feed/mp3. This rule is missing right now because it causes a loop somehow.

It works fine for https://podcast.funkenstrahlen.de/fs/mp3 => http://podcast.funkenstrahlen.de/feed/mp3