Download von MP4-Dateien schlägt fehl (Mediathekview 14.5.0)
-
Ich glaube, daß der beschriebene Fehler nichts mit dem Parameter zu tun hat, daß es sich vielmehr um denselben handelt, den ich in einem anderen Zusammenhang (ich weiß leider nicht, wie ich von hier aus drauf verweisen kann) beschrieben habe.
Ganz genau das, was oben beschrieben wird, tritt bei mir ebenfalls auf und zwar nicht nur beim ORF und ist neu ab Versionen irgendwo > 14.0 bis zu den instabilen 14.6.
Beobachtungen:
- Fast alle Filme werden zwar geladen (Bytes trudeln ein), aber nicht abgespeichert (Dateiname der MPEG-Datei erscheint nicht), IMMER DANN, WENN Untertitel mit ausgewählt sind – die Untertitel selbst werden zuvor geschrieben.
- Wähle ich die Untertitel ab und versuche es danach erneut, bleiben eventuell bereits geladene Untertitel stehen, der Film wird dann normal geladen und auch geschrieben.
- Das „Normale Laden“ kann aus anderen Gründen natürlich dennoch fehlschlagen.
- Manche Filme werden ganz normal geladen, auch wenn Untertitel ausgewählt sind, das sind bei mir jedoch wenige Ausnahmen gewesen, bei denen ich leider noch kein „Muster“ erkennen konnte.
Unglücklicherweise habe auch ich das zunächst für einen anderen Fehler, beziehungsweise eine Nebenwirkung eines Reparaturversuchs gehalten, ich denke momentan jedoch, daß alles darauf hindeutet, daß dies bei der Änderung der Untertitel-Funktion „eingeschleppt“ worden ist. (Davon, also einer Untertitel-Änderung, wurde hier im Forum berichtet und es deckt sich mit meinen Beobachtungen: wenn zusätzlich Dateien mit der Endung „ass“ auftauchen, dann bei mir auch dieses Problem. [Vielleicht ist „ass“ ja das Muster, das mir bislang entgangen war, da schien es keine von zu geben, wenn es klappte, kann ich aber nachträglich nicht prüfen, da ich mir nicht gemerkt habe, welche Dateien auf Anhieb gingen, sondern nur, daß dies die große Ausnahem war.])
Begründung dafür, daß es nicht dran liegt, daß die ORF-Spinner Mediathekview „hassen“: dann würde die Verbindung abgebrochen, nicht aber der Film geladen und nur am Ende die Datei nicht angelegt. Auf das Schreiben selbst hat der ORF keinen Einfluß, der kann sich nur weigern, die Bytes überhaupt auszuliefern.
-
Ich glaube, daß der beschriebene Fehler nichts mit dem Parameter zu tun hat, daß es sich vielmehr um denselben handelt, den ich in einem anderen Zusammenhang (ich weiß leider nicht, wie ich von hier aus drauf verweisen kann) beschrieben habe.
Ganz genau das, was oben beschrieben wird, tritt bei mir ebenfalls auf und zwar nicht nur beim ORF und ist neu ab Versionen irgendwo > 14.0 bis zu den instabilen 14.6.
Beobachtungen:
- Fast alle Filme werden zwar geladen (Bytes trudeln ein), aber nicht abgespeichert (Dateiname der MPEG-Datei erscheint nicht), IMMER DANN, WENN Untertitel mit ausgewählt sind – die Untertitel selbst werden zuvor geschrieben.
- Wähle ich die Untertitel ab und versuche es danach erneut, bleiben eventuell bereits geladene Untertitel stehen, der Film wird dann normal geladen und auch geschrieben.
- Das „Normale Laden“ kann aus anderen Gründen natürlich dennoch fehlschlagen.
- Manche Filme werden ganz normal geladen, auch wenn Untertitel ausgewählt sind, das sind bei mir jedoch wenige Ausnahmen gewesen, bei denen ich leider noch kein „Muster“ erkennen konnte.
Unglücklicherweise habe auch ich das zunächst für einen anderen Fehler, beziehungsweise eine Nebenwirkung eines Reparaturversuchs gehalten, ich denke momentan jedoch, daß alles darauf hindeutet, daß dies bei der Änderung der Untertitel-Funktion „eingeschleppt“ worden ist. (Davon, also einer Untertitel-Änderung, wurde hier im Forum berichtet und es deckt sich mit meinen Beobachtungen: wenn zusätzlich Dateien mit der Endung „ass“ auftauchen, dann bei mir auch dieses Problem. [Vielleicht ist „ass“ ja das Muster, das mir bislang entgangen war, da schien es keine von zu geben, wenn es klappte, kann ich aber nachträglich nicht prüfen, da ich mir nicht gemerkt habe, welche Dateien auf Anhieb gingen, sondern nur, daß dies die große Ausnahem war.])
Begründung dafür, daß es nicht dran liegt, daß die ORF-Spinner Mediathekview „hassen“: dann würde die Verbindung abgebrochen, nicht aber der Film geladen und nur am Ende die Datei nicht angelegt. Auf das Schreiben selbst hat der ORF keinen Einfluß, der kann sich nur weigern, die Bytes überhaupt auszuliefern.
@CHF sagte in Download von MP4-Dateien schlägt fehl (Mediathekview 14.5.0):
Ich glaube, daß der beschriebene Fehler nichts mit dem Parameter zu tun hat, daß es sich vielmehr um denselben handelt, den ich in einem anderen Zusammenhang (ich weiß leider nicht, wie ich von hier aus drauf verweisen kann) beschrieben habe.
Ganz genau das, was oben beschrieben wird, tritt bei mir ebenfalls auf und zwar nicht nur beim ORF und ist neu ab Versionen irgendwo > 14.0 bis zu den instabilen 14.6.
Beobachtungen:
- Fast alle Filme werden zwar geladen (Bytes trudeln ein), aber nicht abgespeichert (Dateiname der MPEG-Datei erscheint nicht), IMMER DANN, WENN Untertitel mit ausgewählt sind – die Untertitel selbst werden zuvor geschrieben.
- Wähle ich die Untertitel ab und versuche es danach erneut, bleiben eventuell bereits geladene Untertitel stehen, der Film wird dann normal geladen und auch geschrieben.
- Das „Normale Laden“ kann aus anderen Gründen natürlich dennoch fehlschlagen.
- Manche Filme werden ganz normal geladen, auch wenn Untertitel ausgewählt sind, das sind bei mir jedoch wenige Ausnahmen gewesen, bei denen ich leider noch kein „Muster“ erkennen konnte.
Unglücklicherweise habe auch ich das zunächst für einen anderen Fehler, beziehungsweise eine Nebenwirkung eines Reparaturversuchs gehalten, ich denke momentan jedoch, daß alles darauf hindeutet, daß dies bei der Änderung der Untertitel-Funktion „eingeschleppt“ worden ist. (Davon, also einer Untertitel-Änderung, wurde hier im Forum berichtet und es deckt sich mit meinen Beobachtungen: wenn zusätzlich Dateien mit der Endung „ass“ auftauchen, dann bei mir auch dieses Problem. [Vielleicht ist „ass“ ja das Muster, das mir bislang entgangen war, da schien es keine von zu geben, wenn es klappte, kann ich aber nachträglich nicht prüfen, da ich mir nicht gemerkt habe, welche Dateien auf Anhieb gingen, sondern nur, daß dies die große Ausnahem war.])
Begründung dafür, daß es nicht dran liegt, daß die ORF-Spinner Mediathekview „hassen“: dann würde die Verbindung abgebrochen, nicht aber der Film geladen und nur am Ende die Datei nicht angelegt. Auf das Schreiben selbst hat der ORF keinen Einfluß, der kann sich nur weigern, die Bytes überhaupt auszuliefern.
@chf Du machst dich lächerlich. Das hier hat überhaupt nix mit deinem vermeintlichen Problem zu tun. Dem OP zufolge werden auch nur die Untertitel erfolgreich geladen, NICHT jedoch der Film selbst - und dieses Verhalten ist genau so erwartbar. Somit ist allein dein letzter Absatz völliger Quatsch. Und auch die Fehlermeldung die ich gepostet habe mit dem Befehl des OP zeigt genau das: es wird nix geladen weil
access denied…Im übrigen läuft der Download von Untertiteln völlig losgelöst von allen anderen Downloads - sie werden nur angestossen wenn die Dateien gewünscht werden und dann konvertiert. Ein Erfolg des DL hängt nicht von den Untertiteln ab. Musst du nicht glauben, steht aber so im code.
DEIN vermeintliches Problem ist ein vermeintlich fehlerhafter HTTP Download direkt aus MV heraus, hier jedoch geht es um einen
ffmpegDownload der fehlschlägt weil der ORF ganz klar ohne zusätzliche Parameter eindeutigHTTP error 403 Forbiddenmeldet. Das ist ein seit langem bekanntes Verhalten des ORF in Bezug auf Geo-blocking - und es gibt auch ausführliche Anleitungen hier im Forum wie man das einstellen muss. Und es hat rein gar nichts mit dem anderen Thread zu tun. Und btw, nimmt man das von @vitusson angepasste kommando wird dann auch der Film erfolgreich aus Deutschland geladen. Nicht mehr und nicht weniger. -
@CHF sagte in Download von MP4-Dateien schlägt fehl (Mediathekview 14.5.0):
Ich glaube, daß der beschriebene Fehler nichts mit dem Parameter zu tun hat, daß es sich vielmehr um denselben handelt, den ich in einem anderen Zusammenhang (ich weiß leider nicht, wie ich von hier aus drauf verweisen kann) beschrieben habe.
Ganz genau das, was oben beschrieben wird, tritt bei mir ebenfalls auf und zwar nicht nur beim ORF und ist neu ab Versionen irgendwo > 14.0 bis zu den instabilen 14.6.
Beobachtungen:
- Fast alle Filme werden zwar geladen (Bytes trudeln ein), aber nicht abgespeichert (Dateiname der MPEG-Datei erscheint nicht), IMMER DANN, WENN Untertitel mit ausgewählt sind – die Untertitel selbst werden zuvor geschrieben.
- Wähle ich die Untertitel ab und versuche es danach erneut, bleiben eventuell bereits geladene Untertitel stehen, der Film wird dann normal geladen und auch geschrieben.
- Das „Normale Laden“ kann aus anderen Gründen natürlich dennoch fehlschlagen.
- Manche Filme werden ganz normal geladen, auch wenn Untertitel ausgewählt sind, das sind bei mir jedoch wenige Ausnahmen gewesen, bei denen ich leider noch kein „Muster“ erkennen konnte.
Unglücklicherweise habe auch ich das zunächst für einen anderen Fehler, beziehungsweise eine Nebenwirkung eines Reparaturversuchs gehalten, ich denke momentan jedoch, daß alles darauf hindeutet, daß dies bei der Änderung der Untertitel-Funktion „eingeschleppt“ worden ist. (Davon, also einer Untertitel-Änderung, wurde hier im Forum berichtet und es deckt sich mit meinen Beobachtungen: wenn zusätzlich Dateien mit der Endung „ass“ auftauchen, dann bei mir auch dieses Problem. [Vielleicht ist „ass“ ja das Muster, das mir bislang entgangen war, da schien es keine von zu geben, wenn es klappte, kann ich aber nachträglich nicht prüfen, da ich mir nicht gemerkt habe, welche Dateien auf Anhieb gingen, sondern nur, daß dies die große Ausnahem war.])
Begründung dafür, daß es nicht dran liegt, daß die ORF-Spinner Mediathekview „hassen“: dann würde die Verbindung abgebrochen, nicht aber der Film geladen und nur am Ende die Datei nicht angelegt. Auf das Schreiben selbst hat der ORF keinen Einfluß, der kann sich nur weigern, die Bytes überhaupt auszuliefern.
@chf Du machst dich lächerlich. Das hier hat überhaupt nix mit deinem vermeintlichen Problem zu tun. Dem OP zufolge werden auch nur die Untertitel erfolgreich geladen, NICHT jedoch der Film selbst - und dieses Verhalten ist genau so erwartbar. Somit ist allein dein letzter Absatz völliger Quatsch. Und auch die Fehlermeldung die ich gepostet habe mit dem Befehl des OP zeigt genau das: es wird nix geladen weil
access denied…Im übrigen läuft der Download von Untertiteln völlig losgelöst von allen anderen Downloads - sie werden nur angestossen wenn die Dateien gewünscht werden und dann konvertiert. Ein Erfolg des DL hängt nicht von den Untertiteln ab. Musst du nicht glauben, steht aber so im code.
DEIN vermeintliches Problem ist ein vermeintlich fehlerhafter HTTP Download direkt aus MV heraus, hier jedoch geht es um einen
ffmpegDownload der fehlschlägt weil der ORF ganz klar ohne zusätzliche Parameter eindeutigHTTP error 403 Forbiddenmeldet. Das ist ein seit langem bekanntes Verhalten des ORF in Bezug auf Geo-blocking - und es gibt auch ausführliche Anleitungen hier im Forum wie man das einstellen muss. Und es hat rein gar nichts mit dem anderen Thread zu tun. Und btw, nimmt man das von @vitusson angepasste kommando wird dann auch der Film erfolgreich aus Deutschland geladen. Nicht mehr und nicht weniger.@DerReisende77 sagte in Download von MP4-Dateien schlägt fehl (Mediathekview 14.5.0):
@CHF sagte in Download von MP4-Dateien schlägt fehl (Mediathekview 14.5.0):
[…]
@chf Du machst dich lächerlich.
Benimm Dich bitte; Du hast mich ganz offensichtlich nicht richtig verstanden; auf Einzelheiten werde ich noch eingehen. Leute zu beschimpfen, von denen Du glaubst, daß sie sich irren, führt unterdessen zu keiner Verbesserung des Programms.
-
@chf Ich habe dich sehr wohl verstanden. Und auch dass deine Ausführungen rein gar nichts mit dem hier beschriebenen Problem zu tun haben. Musst Du mir aber auch nicht glauben, ich hab den scheiß hier ja nur programmiert…
Wie dem auch sei: Es wird in allen deiner Threads von meiner Seite keinerlei Kommentare oder wasauchimmer mehr geben. Da ich dummerweise aber auch der einzige bin der das ggf. umsetzen müsste wirds halt schwierig.
-
Ich glaube, daß der beschriebene Fehler nichts mit dem Parameter zu tun hat, daß es sich vielmehr um denselben handelt, den ich in einem anderen Zusammenhang (ich weiß leider nicht, wie ich von hier aus drauf verweisen kann) beschrieben habe.
Ganz genau das, was oben beschrieben wird, tritt bei mir ebenfalls auf und zwar nicht nur beim ORF und ist neu ab Versionen irgendwo > 14.0 bis zu den instabilen 14.6.
Beobachtungen:
- Fast alle Filme werden zwar geladen (Bytes trudeln ein), aber nicht abgespeichert (Dateiname der MPEG-Datei erscheint nicht), IMMER DANN, WENN Untertitel mit ausgewählt sind – die Untertitel selbst werden zuvor geschrieben.
- Wähle ich die Untertitel ab und versuche es danach erneut, bleiben eventuell bereits geladene Untertitel stehen, der Film wird dann normal geladen und auch geschrieben.
- Das „Normale Laden“ kann aus anderen Gründen natürlich dennoch fehlschlagen.
- Manche Filme werden ganz normal geladen, auch wenn Untertitel ausgewählt sind, das sind bei mir jedoch wenige Ausnahmen gewesen, bei denen ich leider noch kein „Muster“ erkennen konnte.
Unglücklicherweise habe auch ich das zunächst für einen anderen Fehler, beziehungsweise eine Nebenwirkung eines Reparaturversuchs gehalten, ich denke momentan jedoch, daß alles darauf hindeutet, daß dies bei der Änderung der Untertitel-Funktion „eingeschleppt“ worden ist. (Davon, also einer Untertitel-Änderung, wurde hier im Forum berichtet und es deckt sich mit meinen Beobachtungen: wenn zusätzlich Dateien mit der Endung „ass“ auftauchen, dann bei mir auch dieses Problem. [Vielleicht ist „ass“ ja das Muster, das mir bislang entgangen war, da schien es keine von zu geben, wenn es klappte, kann ich aber nachträglich nicht prüfen, da ich mir nicht gemerkt habe, welche Dateien auf Anhieb gingen, sondern nur, daß dies die große Ausnahem war.])
Begründung dafür, daß es nicht dran liegt, daß die ORF-Spinner Mediathekview „hassen“: dann würde die Verbindung abgebrochen, nicht aber der Film geladen und nur am Ende die Datei nicht angelegt. Auf das Schreiben selbst hat der ORF keinen Einfluß, der kann sich nur weigern, die Bytes überhaupt auszuliefern.
@CHF sagte: Ich glaube, daß der beschriebene Fehler nichts mit dem Parameter zu tun hat
Das ist keine Glaubensfrage, probiere doch einfach mal – nach dieser in der Kategorie “Fragen, Hilfe, Kritik” angepinnten Anleitung – einen User-Agent zu ergänzen und berichte erneut.
@CHF sagte: auf Einzelheiten werde ich noch eingehen
Bitte nicht, bitte mach dich besser mal etwas im Forum schlau und mach danach ausführlichere Tests. Deine bisherigen, ausufernden Ausführungen haben bislang keine neuen Erkenntnisse gebracht und blähen das Forum nur unnötig auf…
-
Ich glaube, daß der beschriebene Fehler nichts mit dem Parameter zu tun hat, daß es sich vielmehr um denselben handelt, den ich in einem anderen Zusammenhang (ich weiß leider nicht, wie ich von hier aus drauf verweisen kann) beschrieben habe.
Ganz genau das, was oben beschrieben wird, tritt bei mir ebenfalls auf und zwar nicht nur beim ORF und ist neu ab Versionen irgendwo > 14.0 bis zu den instabilen 14.6.
Beobachtungen:
- Fast alle Filme werden zwar geladen (Bytes trudeln ein), aber nicht abgespeichert (Dateiname der MPEG-Datei erscheint nicht), IMMER DANN, WENN Untertitel mit ausgewählt sind – die Untertitel selbst werden zuvor geschrieben.
- Wähle ich die Untertitel ab und versuche es danach erneut, bleiben eventuell bereits geladene Untertitel stehen, der Film wird dann normal geladen und auch geschrieben.
- Das „Normale Laden“ kann aus anderen Gründen natürlich dennoch fehlschlagen.
- Manche Filme werden ganz normal geladen, auch wenn Untertitel ausgewählt sind, das sind bei mir jedoch wenige Ausnahmen gewesen, bei denen ich leider noch kein „Muster“ erkennen konnte.
Unglücklicherweise habe auch ich das zunächst für einen anderen Fehler, beziehungsweise eine Nebenwirkung eines Reparaturversuchs gehalten, ich denke momentan jedoch, daß alles darauf hindeutet, daß dies bei der Änderung der Untertitel-Funktion „eingeschleppt“ worden ist. (Davon, also einer Untertitel-Änderung, wurde hier im Forum berichtet und es deckt sich mit meinen Beobachtungen: wenn zusätzlich Dateien mit der Endung „ass“ auftauchen, dann bei mir auch dieses Problem. [Vielleicht ist „ass“ ja das Muster, das mir bislang entgangen war, da schien es keine von zu geben, wenn es klappte, kann ich aber nachträglich nicht prüfen, da ich mir nicht gemerkt habe, welche Dateien auf Anhieb gingen, sondern nur, daß dies die große Ausnahem war.])
Begründung dafür, daß es nicht dran liegt, daß die ORF-Spinner Mediathekview „hassen“: dann würde die Verbindung abgebrochen, nicht aber der Film geladen und nur am Ende die Datei nicht angelegt. Auf das Schreiben selbst hat der ORF keinen Einfluß, der kann sich nur weigern, die Bytes überhaupt auszuliefern.
@CHF sagte in Download von MP4-Dateien schlägt fehl (Mediathekview 14.5.0):
Ich glaube ja nicht dass deine gehäuften tl;dr Beiträge in mehreren Threads irgendwas hilfrreiches beitragen. Du bastelst dir eine Theorie und wenn man dir erklärt dass sie nicht stimmt wiederholst du sie in 3 langen Beiträgen nochmal…
Filter adjusted
-
@bobby
Betrifft das bei Dir nur Sendungen vom ORF? Oder generell alle Sender?@MenchenSued Tritt auch bei anderen Sendern auf, nicht nur ORF (war nur ein kleines Beispielvideo).
Hab grad nochmal ein anderes Beispiel gesucht und gefunden:
- Nr.: 340565
- Thema: Wer weiß denn sowas?
- Titel: Tanja Wedhorn und Marco Girnth
Mit Version 14.5.0 werden folgende Dateien ins Download-Verzeichnis geschrieben:
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4.ttml
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4.ttml.ass
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4.ttml.srt
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4.txt
Dagegen werden folgende Dateien mit Version 14.4.2 abgelegt:
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.ttml
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.ass
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.srt
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.txt
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4
Auffällig ist, dass bei den Dateinamen von Version 14.5.0 überall .mp4 steht und außer bei der .txt-Datei auch noch .ttml; Die MP4-Datei selber fehlt dabei.
Der Download selbst funktioniert auch noch; auch wenn zu keiner Zeit die MP4-Datei im Download-Verzeichnis zu sehen ist. Nachdem der Download dann fertig ist, erscheint im Programm eine Fehlrmeldung und die MP4-Datei wird erneut “heruntergeladen”.
Hatte noch vergessen zu erwähnen, dass ich Linux (Fedora) verwende.
-
@MenchenSued Tritt auch bei anderen Sendern auf, nicht nur ORF (war nur ein kleines Beispielvideo).
Hab grad nochmal ein anderes Beispiel gesucht und gefunden:
- Nr.: 340565
- Thema: Wer weiß denn sowas?
- Titel: Tanja Wedhorn und Marco Girnth
Mit Version 14.5.0 werden folgende Dateien ins Download-Verzeichnis geschrieben:
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4.ttml
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4.ttml.ass
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4.ttml.srt
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4.txt
Dagegen werden folgende Dateien mit Version 14.4.2 abgelegt:
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.ttml
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.ass
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.srt
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.txt
- Wer_weiß_denn_sowas?-Tanja_Wedhorn_und_Marco_Girnth-0911161823.mp4
Auffällig ist, dass bei den Dateinamen von Version 14.5.0 überall .mp4 steht und außer bei der .txt-Datei auch noch .ttml; Die MP4-Datei selber fehlt dabei.
Der Download selbst funktioniert auch noch; auch wenn zu keiner Zeit die MP4-Datei im Download-Verzeichnis zu sehen ist. Nachdem der Download dann fertig ist, erscheint im Programm eine Fehlrmeldung und die MP4-Datei wird erneut “heruntergeladen”.
Hatte noch vergessen zu erwähnen, dass ich Linux (Fedora) verwende.
@bobby sagte: Tritt auch bei anderen Sendern auf, nicht nur ORF.
Ja, bei BR und NDR (zu welchem dein neues Beispiel zugehörig ist), wobei in diesem Fall eine komplett andere Ursache als bei deinem ORF-Beispiel vorliegt und der Fehler sich ja auch in anderer Form zeigt (ORF: Meldung “fehlerhaft” kommt sofort; NDR: mehrere Retries bis “fehlerhaft”).
Was beim ORF das Problem ist und wie man es lösen kann, wurde oben bereits mehrfach erwähnt.@bobby sagte: Nachdem der Download dann fertig ist, erscheint im Programm eine Fehlrmeldung und die MP4-Datei wird erneut “heruntergeladen”.
Ich konnte das mit einer nicht-geogeblockten Sendung (Sender: NDR; Thema: Die Nordreportage; Titel: Wie geht das? Fertigung eines Windrades) mit MV 14.5.0 unter macOS Ventura verifizieren:
-
D.h., der Download scheint fertig zu sein:
-
Dann übersteigt während einer Zehntelsekunde die DL-Grösse die angegebene Grösse:
-
Der DL startet erneut – ohne Userinteraktion und Fenster mit Fehlermeldung wie “Stream was reset”. Erst nach dem dritten Anlauf stoppt der Download mit “fehlerhaft”:
Tatsächlich konnte ich die Sendung dreimal hintereinander erfolgreich herunterladen, wenn ich auf den zeitgleichen Untertitel-Download verzichtete. Evtl. ist das eine Sperre ausgelöst durch zwei gleichzeitige Downloads vom Server (Video- und UT-Datei).
@derreisende77: Mit der Nightly-Version von heute 9.4.2026 scheint dieses Problem jedoch gelöst zu sein. Little Snitch meldet mir mit der Nightly auch zwei zusätzliche UDP-Verbindungen und eine TCP-Verbindung zu einem Akamai-Server, was wohl deinen Beschreibungen in deinem letzten Post entspricht.
Wenn ich die Option “CDN-aware Downloader verwenden” deselektiere, dann habe ich erwartungsgemäss das gleiche Verhalten wie bei 14.5.0.@bobby sagte: Auffällig ist, dass bei den Dateinamen von Version 14.5.0 überall .mp4 steht und außer bei der .txt-Datei auch noch .ttml
Mit 14.5.0 wurde der Untertitel-Format-Support vollständig neu implementiert und zumindest beim NDR erscheinen die Untertitel wohl unabsichtlicherweise mit doppelter Dateiendung (bei anderen Sendern wie dem SRF, ORF, ARD, ZDF ist das nicht der Fall). Ich hab in dieser Sache ein Ticket erstellt.
SRT- und ASS-Untertitel werden im Unterschied zur .txt-Datei aus der .ttml-Datei aus der Mediathek lokal durch MV erzeugt (deshalb stehen die TTML-Endung auch noch da). Die .txt-Datei wird aus den Daten der Filmliste erzeugt.
-
@bobby sagte: Tritt auch bei anderen Sendern auf, nicht nur ORF.
Ja, bei BR und NDR (zu welchem dein neues Beispiel zugehörig ist), wobei in diesem Fall eine komplett andere Ursache als bei deinem ORF-Beispiel vorliegt und der Fehler sich ja auch in anderer Form zeigt (ORF: Meldung “fehlerhaft” kommt sofort; NDR: mehrere Retries bis “fehlerhaft”).
Was beim ORF das Problem ist und wie man es lösen kann, wurde oben bereits mehrfach erwähnt.@bobby sagte: Nachdem der Download dann fertig ist, erscheint im Programm eine Fehlrmeldung und die MP4-Datei wird erneut “heruntergeladen”.
Ich konnte das mit einer nicht-geogeblockten Sendung (Sender: NDR; Thema: Die Nordreportage; Titel: Wie geht das? Fertigung eines Windrades) mit MV 14.5.0 unter macOS Ventura verifizieren:
-
D.h., der Download scheint fertig zu sein:
-
Dann übersteigt während einer Zehntelsekunde die DL-Grösse die angegebene Grösse:
-
Der DL startet erneut – ohne Userinteraktion und Fenster mit Fehlermeldung wie “Stream was reset”. Erst nach dem dritten Anlauf stoppt der Download mit “fehlerhaft”:
Tatsächlich konnte ich die Sendung dreimal hintereinander erfolgreich herunterladen, wenn ich auf den zeitgleichen Untertitel-Download verzichtete. Evtl. ist das eine Sperre ausgelöst durch zwei gleichzeitige Downloads vom Server (Video- und UT-Datei).
@derreisende77: Mit der Nightly-Version von heute 9.4.2026 scheint dieses Problem jedoch gelöst zu sein. Little Snitch meldet mir mit der Nightly auch zwei zusätzliche UDP-Verbindungen und eine TCP-Verbindung zu einem Akamai-Server, was wohl deinen Beschreibungen in deinem letzten Post entspricht.
Wenn ich die Option “CDN-aware Downloader verwenden” deselektiere, dann habe ich erwartungsgemäss das gleiche Verhalten wie bei 14.5.0.@bobby sagte: Auffällig ist, dass bei den Dateinamen von Version 14.5.0 überall .mp4 steht und außer bei der .txt-Datei auch noch .ttml
Mit 14.5.0 wurde der Untertitel-Format-Support vollständig neu implementiert und zumindest beim NDR erscheinen die Untertitel wohl unabsichtlicherweise mit doppelter Dateiendung (bei anderen Sendern wie dem SRF, ORF, ARD, ZDF ist das nicht der Fall). Ich hab in dieser Sache ein Ticket erstellt.
SRT- und ASS-Untertitel werden im Unterschied zur .txt-Datei aus der .ttml-Datei aus der Mediathek lokal durch MV erzeugt (deshalb stehen die TTML-Endung auch noch da). Die .txt-Datei wird aus den Daten der Filmliste erzeugt.
@styroll sagte in Download von MP4-Dateien schlägt fehl (Mediathekview 14.5.0):
@derreisende77: Mit der Nightly-Version von heute 9.4.2026 scheint dieses Problem jedoch gelöst zu sein. Little Snitch meldet mir mit der Nightly auch zwei zusätzliche UDP-Verbindungen und eine TCP-Verbindung zu einem Akamai-Server, was wohl deinen Beschreibungen in deinem letzten Post entspricht.
Wenn ich die Option “CDN-aware Downloader verwenden” deselektiere, dann habe ich erwartungsgemäss das gleiche Verhalten wie bei 14.5.0.Na das ist ja schon mal gut zu hören dass es nun klappt. Die UDP-Verbindung dürfte DNS sein, ich muss nun bei jedem Verbindungsaufbau DNS-Abfragen machen was vorher nicht nötig war.
@bobby sagte: Auffällig ist, dass bei den Dateinamen von Version 14.5.0 überall .mp4 steht und außer bei der .txt-Datei auch noch .ttml
Mit 14.5.0 wurde der Untertitel-Format-Support vollständig neu implementiert und zumindest beim NDR erscheinen die Untertitel wohl unabsichtlicherweise mit doppelter Dateiendung (bei anderen Sendern wie dem SRF, ORF, ARD, ZDF ist das nicht der Fall). Ich hab in dieser Sache ein Ticket erstellt.
Wie im Ticket beschrieben lag das Problem an dem
?im Namen was den Helper für die Erzeugung eines Dateinamen durcheinander brachte. Ist im nightly heute nacht bzw. morgen auch für die Allgemeinheit behoben.Open source developers do NOT have to:
- Make your issue a priority, just because you say so.
- Give you any sort of "timetable", or explanation for why it´s "taking too long".
Check your entitlement. Nobody owes you anything.
-
-
@styroll sagte in Download von MP4-Dateien schlägt fehl (Mediathekview 14.5.0):
@derreisende77: Mit der Nightly-Version von heute 9.4.2026 scheint dieses Problem jedoch gelöst zu sein. Little Snitch meldet mir mit der Nightly auch zwei zusätzliche UDP-Verbindungen und eine TCP-Verbindung zu einem Akamai-Server, was wohl deinen Beschreibungen in deinem letzten Post entspricht.
Wenn ich die Option “CDN-aware Downloader verwenden” deselektiere, dann habe ich erwartungsgemäss das gleiche Verhalten wie bei 14.5.0.Na das ist ja schon mal gut zu hören dass es nun klappt. Die UDP-Verbindung dürfte DNS sein, ich muss nun bei jedem Verbindungsaufbau DNS-Abfragen machen was vorher nicht nötig war.
@bobby sagte: Auffällig ist, dass bei den Dateinamen von Version 14.5.0 überall .mp4 steht und außer bei der .txt-Datei auch noch .ttml
Mit 14.5.0 wurde der Untertitel-Format-Support vollständig neu implementiert und zumindest beim NDR erscheinen die Untertitel wohl unabsichtlicherweise mit doppelter Dateiendung (bei anderen Sendern wie dem SRF, ORF, ARD, ZDF ist das nicht der Fall). Ich hab in dieser Sache ein Ticket erstellt.
Wie im Ticket beschrieben lag das Problem an dem
?im Namen was den Helper für die Erzeugung eines Dateinamen durcheinander brachte. Ist im nightly heute nacht bzw. morgen auch für die Allgemeinheit behoben.@DerReisende77 sagte: Wie im Ticket beschrieben lag das Problem an dem ? im Namen
Ich hab natürlich schon zwei Fälle als Basis für ein Ticket genommen, aber unglücklicherweise hatten sowohl das Beispiel des OP wie auch meines unter GitHub ein “?” im Namen. Aber immerhin ergibt es nun Sinn, dass dieser Thread sich im Entwicklerforum befindet (welches für das ORF-Problem nicht die richtige Kategorie wäre)…
@DerReisende77 sagt: Die UDP-Verbindung dürfte DNS sein
Das ist zutreffend:
