Assets verifizieren schlägt fehl (Apple Podcasts indiziert Episode nicht, Web-Player findet File nicht)

Hallo zusammen,

zuallererst möchte ich mich vorab bei den MacherInnen von Podlove bedanken. Was ihr entwickelt ist super und ich bin ein großer Fan! :relaxed:
Weiters möchte ich darauf hinweisen, dass ich nicht 100% sicher bin, ob der Podlove Publisher tatsächlich das Problem ist oder er selbst unter einem anderen Problem „leidet“ und ich im Publisher nur die Symptome wahrnehmen kann (daher habe ich erstmal auch kein Git-Issue eröffnet). Jedoch hoffe ich, dass ich über diesen Post hier womöglich die richtigen ExpertInnen erreichen kann, die sich sowohl mit Podcasting, Wordpress als auch dem Podlove-Publisher auskennen und mich hier beim Finden des Problems bzw der Lösung unterstützen können. Ich wäre wahnsinnig dankbar, weil ich mir schon bissl die Haare raufe und ich schon mit meinem Latein … ähh … php am Ende bin.

Problem:
Das Verifizieren von Assets im Episode-Editieren-Formular schlägt neuerdings immer fehl.
Auch bei alten Episoden, wo das File zuvor gepasst hat, schlägt das Verifizieren jetzt fehl. Danach leiden diese Episoden unter den selben Problemen wie die neuen. Alte Episoden, die ich nicht mehr angefasst habe, funktionieren wohl nach wie vor. Die Lauflänge kann normal erkannt werden. Das File ist unter dem Link erreichbar.
Screenshot 2021-07-03 203633

Auswirkung:
Der Web-Player kann das File nicht mehr abspielen
Screenshot 2021-07-03 203832
Die Folge wird von Apple Podcast anscheinend nicht indiziert
(Der RSS Feed und Spotify scheinen aber nornal zu funktionieren)

Troubleshooting:
Das Problem existiert soweit ich das abschätzen kann seit ca. 2 Wochen (die letzten Folgen vor etwas mehr als 2 Wochen konnten noch problemlos verifizert und veröffentlicht werden). In diesem Zeitraum hat sich (laut Admin-Ausasage) nichts an der Wordpress Installation geändert.
Seither haben wir Wordpress und das Plugin auf die „latest“ Version upgedatet (ohne Besserung).
Wie gesagt sind die Files unter den Links erreichbar (diese werden per FTP hochgeladen, liegen immer im selben Ordner, auch jetzt).
Eine neue Folge anlegen, mit einem alten mp3-Asset (von dem ich weiß dass es früher verfiziert werden konnte) schlägt genauso fehl.
Screenshot 2021-07-03 210214
Podlove Cache wurde geleert (andere Caches sind auch geleert bzw deaktiviert worden).
Podlove „Reparieren“-Funktion wurde ausgeführt

Im Hintergrund scheint irgendwann ein 501-Fehler zu fliegen.
Ich hänge unten noch einen Teil des Debug Logs an.

Wenn jemand noch Ideen hat. was ich ausprobieren kann oder was ich noch testen kann, wäre ich sehr dankbar. Ich hab auch Zugang auf den Server. Hab auch schon versucht mir ein bisschen Debug-Info zu generieren. Aber zB hier wirkt es auf mich, als ob da schon nur ein leeres Objekt rauskommt, hab mich aber nicht so ganz getraut hier grob den Code anzufassen.

Die Reponse auf den Ajax-Call der beim Verifizieren abgesetzt wird schaut übrigens ca so aus:
Call auf .../admin-ajax.php?action=podlove-file-update&file_id=163&slug=test
Response: {"file_url":"https:\/\/kinofilme.com\/files\/eskapoden\/test.mp3","file_id":163,"reachable":false,"file_size":null,"file_size_human":"0"}

Wie gesagt, wenn jemand noch Ideen hat, wir würden uns freuen.
Vielen vielen Dank jedenfalls schonmal im Voraus!

Debug Log
Im debug log des plugins sieht man auch ein paar Probleme:

2021-06-29 20:38:50     Unexpected http response when trying to access remote media file. test/MP3 Audio HTTP Status: 501
---
media_file_id: "163"
http_code: 501
2021-06-29 20:38:50     Curl Error: The requested URL returned error: 501 Not Implemented test/MP3 Audio    
---
media_file_id: "163"
2021-06-29 20:38:50     Unexpected http response when trying to access remote media file. test/MP3 Audio HTTP Status: 501
---
media_file_id: "163"
http_code: 501
2021-06-29 20:38:50     Can\'t reach https://kinofilme.com/files/eskapoden/test.mp3 HTTP Status: 501
---
url: >
  https://kinofilme.com/files/eskapoden/test.mp3
content_type: null
http_code: 501
header_size: 0
request_size: 213
filetime: -1
ssl_verify_result: 0
redirect_count: 0
total_time: 0.005032
namelookup_time: 0.000276
connect_time: 0.000313
pretransfer_time: 0.004923
size_upload: 0
size_download: 0
speed_download: 0
speed_upload: 0
download_content_length: -1
upload_content_length: -1
starttransfer_time: 0.005028
redirect_time: 0
redirect_url: ""
primary_ip: xx.xx.xxx.xx (redacted ;) )
certinfo: |
  Array
  (
  )
primary_port: 443
local_ip:  xx.xx.xxx.xx (redacted)
local_port: 39092
http_version: 2
protocol: 2
ssl_verifyresult: 0
scheme: HTTPS
appconnect_time_us: 4905
connect_time_us: 313
namelookup_time_us: 276
pretransfer_time_us: 4923
redirect_time_us: 0
starttransfer_time_us: 5028
total_time_us: 5032
php_open_basedir: ""
php_curl: true
curl_exec: true

edit: ähnliche Themen wie meines habe ich im Sendegate Forum gefunden, scheinen aber jeweils immer andere Probleme gewesen zu sein. Auch Google-Suche war leider nicht von Erfolg gekrönt.