Fehlermeldung stream was reset
-
Bisher habe ich Version 14.0 genutzt (soweit ich mich erinnere, keine stabile, sondern eine aus der Testphase) und bin damit auf dieses Problem gestoßen. Zunächst habe ich eine 14.6 von Ende März und jetzt die aktuelle vom 3.4. installiert, das war allerdings durch und durch eine „Verschlimmbesserung“.
Bei den vom Problem betroffenen Filmen war es bisher bei mir stets so, daß ein paar MB (2 etwa) geladen wurden, dann brach es ab. Man konnte nach den fest vorgegebenen Wiederholungeversuchen das Laden erneut aktivieren und irgendwann war der Film dann komplett da. Das geht nun noch immer, sogar ein wenig schneller, weil 3 Wiederholungsversuche gmacht werden, die reichen aber bei weitem nicht aus und von einem reinen HTTP/2-Problem merke ich auch nichts, es sei denn, das Zurückfallen auf 1.1 funktioniert in Wahrheit gar nicht, sonst müßte ja nach dem ersten auftretenden Fehler mit 1.1 weitergemacht und der Film vollendet werden. Die schon beschriebene Falschberechnung der bereits heruntergeladenen Megabytes tritt hier nun auch immer auf, soweit ich mich erinnere, war das bei der 14.0 noch nicht so.
Die neue Version schleppt mir indes ein ZUSÄTZLICHES Problem ein: für manche Filme schreibt es keine MP4-Datei, sondern lädt zwar Bytes, manchmal bis zum Abbruch wegen obigen Problems, manchmal problemlos bis zum Ende, dann aber wird gemeldet:
. Download fehlgeschlagen, Datei existiert nicht: /Pfad/zur/Zieldatei.mp4
Tut sie auch nicht; WOHIN gehen aber die geladenen Bytes?
Lege ich die Datei nun leer an (touch /Pfad/zur/Zieldatei.mp4) und wiederhole den Vorgang, wird sie als vorhanden erkannt, nach der Rückfrage, ob sie überschrieben werden soll, jedoch einfach nur entfernt, das Ergebnis bleibt ansonsten gleich. Lege ich während des Herunterladens die Datei wieder an, wird im Dateimanager ein „Blinken“ des Dateinamens angezeigt, der auf Zugriffe darauf hindeutet, aber die Größe ändert sich nicht, am Ende des Ladens wird die Datei entfernt und mit besagter Fehlermeldung quittiert. Es ist kein Rechteproblem, die zugehörigen Textdateien werden problemlos erstellt und es wäre auch seltsam, träte ein solches nur mit der neuen 14.6 auf.Ein weiterer Fehler der neuen Version: man kann ja „Programmsets“ anlegen, ich habe 2 zum Herunterladen, nennen wir sie der Einfachheit halber A mit dem Ziel-Pfad /a/ als Vorgabewert für neue Dateien und B mit /b/. Bislang war es so, daß man VOR dem Öffnen der Auswahl-Liste von der Vorauswahl A auf B umschalten konnte und dann als letzter Verzeichnis-Vorschlag /b/NAME angezeigt wurde, nicht /a/NAME. Das hat sich nun geändert und ist schlecht: wenn man ERST ein „Set“ auswählt, will man doch auch, daß nunmehr der „dranhängende“ Speicherort als neue Vorgabe genommen wird. (NAME wird dabei vom „Thema“ abgeleitet.)
sagte in Fehlermeldung stream was reset:
Die neue Version schleppt mir indes ein ZUSÄTZLICHES Problem ein: für manche Filme schreibt es keine MP4-Datei, sondern lädt zwar Bytes, […], dann aber wird gemeldet:
. Download fehlgeschlagen, Datei existiert nicht: /Pfad/zur/Zieldatei.mp4
Tut sie auch nicht; WOHIN gehen aber die geladenen Bytes?Hier habe ich gerade ein Muster entdeckt:
Es geschieht nicht bei allen Filmen, sondern nur bei denen, zu denen Untertitel geladen werden sollen, aber nicht immer, 2 Ausnahmen habe ich entdeckt: SRF wundert mich nicht, weil das kein HTTP ist und ein ZDF-Film ist auch nicht betroffen. Bei ein paar betroffenen Filmen habe ich jetzt mal das Laden der Untertitel abgewählt und wiederhole die Versuche. Das Ergebnis schreibe ich dann hier rein, dauert etwas.So; scheint geholfen zu haben: wenn man Untertitel abwählt, werden die MP4-Dateien angelegt.
Allem Anschein löscht es dann jedoch die zuvor heruntergeladenen Untertitel oder die waren bei der von mir gerade beobachteten Datei auch nicht angelegt worden… -
sagte in Fehlermeldung stream was reset:
Die neue Version schleppt mir indes ein ZUSÄTZLICHES Problem ein: für manche Filme schreibt es keine MP4-Datei, sondern lädt zwar Bytes, […], dann aber wird gemeldet:
. Download fehlgeschlagen, Datei existiert nicht: /Pfad/zur/Zieldatei.mp4
Tut sie auch nicht; WOHIN gehen aber die geladenen Bytes?Hier habe ich gerade ein Muster entdeckt:
Es geschieht nicht bei allen Filmen, sondern nur bei denen, zu denen Untertitel geladen werden sollen, aber nicht immer, 2 Ausnahmen habe ich entdeckt: SRF wundert mich nicht, weil das kein HTTP ist und ein ZDF-Film ist auch nicht betroffen. Bei ein paar betroffenen Filmen habe ich jetzt mal das Laden der Untertitel abgewählt und wiederhole die Versuche. Das Ergebnis schreibe ich dann hier rein, dauert etwas.So; scheint geholfen zu haben: wenn man Untertitel abwählt, werden die MP4-Dateien angelegt.
Allem Anschein löscht es dann jedoch die zuvor heruntergeladenen Untertitel oder die waren bei der von mir gerade beobachteten Datei auch nicht angelegt worden…sagte in Fehlermeldung stream was reset:
Allem Anschein löscht es dann jedoch die zuvor heruntergeladenen Untertitel oder die waren bei der von mir gerade beobachteten Datei auch nicht angelegt worden…
Meine weiteren Tests haben ergeben, daß einmal heruntergeladene Untertitel nicht gelöscht werden, wenn man den Haken wegmacht und dann ohne lädt, warum bei einem Film laut Filmliste welche da sein sollten, aber nicht waren: keine Ahnung. Bei allen Filmen, die nur geladen zu werden SCHIENEN, ohne daß tatsächlich eine MPEG-Datei geschrieben wurde, half bisher jedoch, die Untertitel abzuwählen, um das Problem zu beseitigen. Warum es in sehr wenigen Fällen (bisher genau 2) trotzdem geklappt hat, Filme mit Untertiteln zu laden, ohne dies in 2 getrennten Durchgängen zu machen, ist mir indes ein Rätsel. Eigentlich sollte nicht vom Server abhängen, ob etwas lokal geschrieben wird oder nicht, solange die Server-Daten offensichtlich geliefert werden. In dem Fall verwirren mich also die beiden Dateien, die das Muster: „Wenn man Untertitel lädt, schreibt das Programm keinen Film“ durchbrechen.
-
Ich hatte das gleiche Problem unter Windows 10 mit zwei mp4-Downloads von BR.
Ein manueller Download im Brave-Browser brach auch ab; ein Fortsetzen gelang wegen Netzwerkfehler nicht.
Auch wget und wget2 (wegen HTTP/2) brachen ohne Zusatzparameter den Download ab.
JD2 war hartnäckiger und nach Stunden erfolgreich.
wget2 konnte ich nicht endlos wiederholen lassen - es scheint den HTTP status code 206 als Abbruchgrund zu nehmen.
wget dagegen hat stückchenweise 2 MiB geladen und war damit schneller als JD2:
wget -c -t 0url -
Ich hatte das gleiche Problem unter Windows 10 mit zwei mp4-Downloads von BR.
Ein manueller Download im Brave-Browser brach auch ab; ein Fortsetzen gelang wegen Netzwerkfehler nicht.
Auch wget und wget2 (wegen HTTP/2) brachen ohne Zusatzparameter den Download ab.
JD2 war hartnäckiger und nach Stunden erfolgreich.
wget2 konnte ich nicht endlos wiederholen lassen - es scheint den HTTP status code 206 als Abbruchgrund zu nehmen.
wget dagegen hat stückchenweise 2 MiB geladen und war damit schneller als JD2:
wget -c -t 0url@Georg-J sagte in Fehlermeldung stream was reset:
wget2 konnte ich nicht endlos wiederholen lassen - es scheint den HTTP status code 206 als Abbruchgrund zu nehmen.
wget dagegen hat stückchenweise 2 MiB geladenDamit bestätigst Du, daß die Abbrüche auch mit HTTP 1.1 stattfinden. Da frage ich mich, woher das plötzliche Auftreten dieses Verhaltens kommt, war ja vorher nicht so.
-
was mich wundert: Beim Film “7 Fragen Zukunft - Russland, Drohnen, Raketen: Wie gut sind wir geschützt?” komme ich mit wget anfangs bei mittlerer Auflösung bis 64 … 82 Mbyte und erst dann fängt das Stottern in 2 MByte Schritten an. Bei hoher und niedriger Auflösung komme ich anfangs nur auf 2 MByte. Auch die Reduktion der Downloadgeschwindigkeit durch den Parameter limit-rate ändert nichts an diesem Verhalten. Wenn es ein allgemeiner Mechanismus beim BR wäre, sollten sich doch alle Dateien gleich verhalten. Ich kann das Spiel beliebig oft wiederholen und sehe keine Sättigung.
-
Hier auch: manche Dateien haben das ab Anfang, bei anderen beginnt es irgendwo mittendrin, aber von da an geht es nur noch in 2-MB-Schrittchen weiter.
Wenn es bei allen Dateien exakt gleich wäre, hätte ich ja eine neue Teufelei der Rechteverwerter-Mafia befürchtet, die uns nur noch „streamen“ und keine Privatkopien mehr machen lassen will – es scheint ja, daß Browser damit klarkommen, sonst hätte der BR jetzt ein Problem. -
206 als HTTP-Code, lese ich oben… Das sollte doch normal sein und nur die Antwort auf eine Anfrage: „Gib mir alles ab Byte Nummer wo-auch-immer-es-abgebrochen-hatte!“, also bei der Wiederaufnahme der zuvor abgebrochenen Verbindung kommen, nicht aber beim Abbruch selbst, schließlich sind die 200er doch alle „positive Erfolgsmeldungen“.
-
sagte in Fehlermeldung stream was reset:
Die neue Version schleppt mir indes ein ZUSÄTZLICHES Problem ein: für manche Filme schreibt es keine MP4-Datei, sondern lädt zwar Bytes, […], dann aber wird gemeldet:
. Download fehlgeschlagen, Datei existiert nicht: /Pfad/zur/Zieldatei.mp4
Tut sie auch nicht; WOHIN gehen aber die geladenen Bytes?Hier habe ich gerade ein Muster entdeckt:
Es geschieht nicht bei allen Filmen, sondern nur bei denen, zu denen Untertitel geladen werden sollen, aber nicht immer, 2 Ausnahmen habe ich entdeckt: SRF wundert mich nicht, weil das kein HTTP ist und ein ZDF-Film ist auch nicht betroffen. Bei ein paar betroffenen Filmen habe ich jetzt mal das Laden der Untertitel abgewählt und wiederhole die Versuche. Das Ergebnis schreibe ich dann hier rein, dauert etwas.So; scheint geholfen zu haben: wenn man Untertitel abwählt, werden die MP4-Dateien angelegt.
Allem Anschein löscht es dann jedoch die zuvor heruntergeladenen Untertitel oder die waren bei der von mir gerade beobachteten Datei auch nicht angelegt worden…@CHF sagte in Fehlermeldung stream was reset:
Es geschieht nicht bei allen Filmen, sondern nur bei denen, zu denen Untertitel geladen werden sollen,
Falsch. Ich lade keine Untertitel - und hatte den Fehler trotzdem schon.
-
@CHF sagte in Fehlermeldung stream was reset:
Es geschieht nicht bei allen Filmen, sondern nur bei denen, zu denen Untertitel geladen werden sollen,
Falsch. Ich lade keine Untertitel - und hatte den Fehler trotzdem schon.
@mac-christian sagte in Fehlermeldung stream was reset:
Ich lade keine Untertitel - und hatte den Fehler trotzdem schon.
Nachdem das Problem auch reproduzierbar mit wget auftritt, brauchen wir nicht im MediathekView nach der Ursache suchen. Es kann natürlich durchaus sein, dass bei der neuen Implementierung des Untertitel-Downloads Seiteneffekte bei der Wiederaufnahme des Videos auftreten, aber das wäre dann ein eigenes Thema.
Wget mit unendlichem Retry scheint ja zu klappen, so dass man zumindest eine provisorische Lösung in MediathekView implementieren könnte.
-
Äh – das meinte ich oben mit „2 Fehlern“: der mit den Untertiteln wurde zusätzlich eingeschleppt, entweder unabhängig von dem „Hauptthema“ hier oder beim Versuch, diesen Fehler zu beheben.
Ich habe bei mir das Phänomen gesehen, daß die neue Version eine Verbesserung nur insoweit brachte, als daß durch die 3 Wiederholungsversuche bei den betroffenen Dateien nunmehr etwas mehr „am Stück“ geladen wird, im Gegenzug dazu aber ANDERE Dateien plötzlich zusätzlich zu den BR-„Kandidaten“ Abbrüche zeigten, das meinte ich in meinem 1. Beitrag hierzu mit „Verschlimmbesserung“.
Inzwischen bin ich sicher, daß es 2 ganz unterschiedliche Fehler sind, die allenfalls dergestalt zusammenhängen, als daß der 2. eingebaut worden sein KÖNNTE, beim Versuch den BR-Fehler zu beheben – wenn indes das Untertitel-Laden zwischen Version 14.0 & 14.6 geändert worden ist, dann ist es wohl wahrscheinlicher, daß DABEI der 2. Fehler eingebaut wurde.
Ich habe halt beim Auftreten des BR-Fehlers von 14.0 auf 14.6 gewechselt und hatte danach Fehler bei MEHR Filmen als zuvor, aber dafür wurden längere Stückchen geladen, bevor es abbrach, so sah es für mich aus, als wäre die Fehlerbehebung „nach hinten losgegangen”.
-
206 als HTTP-Code, lese ich oben… Das sollte doch normal sein und nur die Antwort auf eine Anfrage: „Gib mir alles ab Byte Nummer wo-auch-immer-es-abgebrochen-hatte!“, also bei der Wiederaufnahme der zuvor abgebrochenen Verbindung kommen, nicht aber beim Abbruch selbst, schließlich sind die 200er doch alle „positive Erfolgsmeldungen“.
-
M MenchenSued hat auf dieses Thema verwiesen
-
@CHF sagte in Fehlermeldung stream was reset:
Es geschieht nicht bei allen Filmen, sondern nur bei denen, zu denen Untertitel geladen werden sollen,
Falsch. Ich lade keine Untertitel - und hatte den Fehler trotzdem schon.
@mac-christian sagte in Fehlermeldung stream was reset:
@CHF sagte in Fehlermeldung stream was reset:
Es geschieht nicht bei allen Filmen, sondern nur bei denen, zu denen Untertitel geladen werden sollen,
Falsch. Ich lade keine Untertitel - und hatte den Fehler trotzdem schon.
Wie geschrieben gehe ich nunmehr von 2 verschiedenen Fehlern aus. Der hier ursprünglich beschriebene äußert sich so, daß ab Anfang oder einer bestimmten Stelle nur noch etwa 2 MiB „am Stück“ geladen werden, mit automatischen Widerholungsversuchen komme ich auf ein klein wenig >25 MiB, ohne manuell fortsetzen zu müssen.
Das Problem, das nur Filme mit Untertitel betrifft, ist anscheinend ein anderes. Weitere Versuche haben bei mir nur Ausnahmen „andersherum“ hervorgebracht, also wenige Filme, die trotz der gleichzeitig ausgewählten Untertitel heruntergeladen worden sind – jene dann wahrscheinlich ohne Unterbrechung, zumindest waren sie stets länger als die wenigen >25 MiB, die bei mir ohne manuellen Neustart zusammenkommen, wenn das hier ursprünglich beschriebene „BR-Problem“ (zusätzlich) auftritt. Ich habe keinen Fall gefunden, wo das „Filmdatei-Nicht-Lade-Problem“ aufgetreten ist, OHNE DAß Untertitel zu laden gewesen wären – es gibt aber Filme, bei denen die Untetitel und danach die eigentliche Filmdatei problemlos komplett geladen werden, hier bei mir aber nur sehr wenige, ein Muster habe ich da auch noch nicht entdeckt.
Mit meiner Bemerkung war NUR dieses 2. Problem gemeint, das „BR-Problem“ kann nach meiner Beobachtung zu jenem zusätzlich beim selben Film auftreten, muß aber nicht, diese 2 Fehler scheinen unabhängig voneinander zu sein.
Ich hatte die Fehler wohl nur „geistig verbunden“, weil ich nach einer Aktualisierung von 14.0 auf 14.6, um das 1. Problem zu beheben, dann plötzlich auch das 2. hatte, also auf einmal NOCH MEHR Filme als zuvor mit der alten Version bei mir fehlschlugen. Für diese „zusätzlich betroffenen“ Filme konnte ich ein Muster finden: tritt nur mit Untertitel-Laden auf und geht weg, wenn man diese abwählt; dieser Fehler verhält sich auch anders dergestalt, daß sehr wohl Bytes geladen werden – in der Regel der ganze Film –, jedoch nicht „weggeschrieben“ und ganz am Ende des Ladevorgangs bemerkt wird, daß die heruntergeladene Datei gar nicht da ist.
-
@mac-christian sagte in Fehlermeldung stream was reset:
Ich lade keine Untertitel - und hatte den Fehler trotzdem schon.
Nachdem das Problem auch reproduzierbar mit wget auftritt, brauchen wir nicht im MediathekView nach der Ursache suchen. Es kann natürlich durchaus sein, dass bei der neuen Implementierung des Untertitel-Downloads Seiteneffekte bei der Wiederaufnahme des Videos auftreten, aber das wäre dann ein eigenes Thema.
Wget mit unendlichem Retry scheint ja zu klappen, so dass man zumindest eine provisorische Lösung in MediathekView implementieren könnte.
@MenchenSued sagte in Fehlermeldung stream was reset:
Nachdem das Problem auch reproduzierbar mit wget auftritt, brauchen wir nicht im MediathekView nach der Ursache suchen. […]
Wget mit unendlichem Retry scheint ja zu klappen, so dass man zumindest eine provisorische Lösung in MediathekView implementieren könnte.
Es ist ja versucht worden, dem Problem mit Wiederholungsversuchen und Rückfall von HTTP 2 auf 1.1 beizukommen, das klappt eben nur nicht, weil es nicht „notfalls ewig“ wiederholt und die Abbrüche alle um die 2 MiB herum erneut auftreten, wo immer dieser Fehler „zuschlägt“. Bei Filmgrößen von mehreren GB bei hohen Auflösungen und längeren Werken ist eine „Notlösung“ in Mediathekview meines Erachtens unumgänglich, weil das Programm zum Herunterladen ansonsten in Richtung untauglich geht. Solange Web-Browser-Nutzer aus welchem Grund auch immer nicht ebenfalls betroffen sind, dürfte den BR das nicht interessieren.
Zum Thema „Wiederholungen“:
Bei der Version 14.0 ist mir aufgefallen, daß bei Filmen, die noch in der Liste zum Herunterladen standen, aber beispielsweise aus der Mediathek (also die Datei vom Server) gelöscht wurden, „ewig“ versucht wurde, den Film erneut herunterzuladen, sobald nur noch solche Filme in der Liste standen, kam man dann kaum noch zum „Dazwischenklicken“, um das abzubrechen und das hat da noch genervt. Das ist bei der 14.6 nun anders, warum auch immer, es wird auch bei nicht mehr vorhandener Quelldatei nicht „ewig“ wiederholt. Ich schätze, daß man nicht darum herumkommt, „ewige“ Wiederholungsversuche als kleineres Übel erneut einzuführen. -
@chf Deine Analyse und Schlussfolgerungen sind falsch. Die Server haben ein Problem und dies wird auch nicht durch unendliches Neuversuchen besser - denn die gelieferten Daten sind nach dem Reset Müll. Der Wechsel von HTTP/2 auf 1.1. nach einem Fehler ist zielführend, da manche Server mit dem neueren Standard noch ein Problem haben. Jedoch ist der gelieferte Film an sich Datenmüll und kann nicht angeschaut werden.
Auch eine Reduzierung der Bandbreite für den DL verhindert nicht das Problem. Und das Problem tritt neben MV auch mit wget, JDownloader und auch bei mir zusätzlich mit yt-dlp auf - unabhängig von der gewählten Auflösung. Von daher gesehen besteht aus Sicht von MV kein Grund weitere Änderungen vorzunehmen die nichts bewirken. Niemand kann hexen - aber man könnte auf Seiten der Sender mal die Fehler beheben.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.
-
@menchensued Beim Download des Beitrages des BR “Cashback, Handwerker-Abzocke, High–mehr_wert-BR.mp4” wird eine Dateigröße von 1141 angezeigt. Während des Downloads wird die Downloadgröße allerdings dann größer als die vorab gezeigte Größe. Das ist mir bei anderen Downloads nicht aufgefallen. Vielleicht hilft dieser Hinweis?
Ich stimme der Meinung vom derreisende77 zu, dass das Problem beim BR liegt, was immer die auch gemacht haben - es wurde verschlimmbessert. Wer spricht mit dem Sender? Gibt es dort eine gewisse Aufmerksamkeit für diese tolle Software, die ich nicht mehr missen möchte. -
@chf Deine Analyse und Schlussfolgerungen sind falsch. Die Server haben ein Problem und dies wird auch nicht durch unendliches Neuversuchen besser - denn die gelieferten Daten sind nach dem Reset Müll. Der Wechsel von HTTP/2 auf 1.1. nach einem Fehler ist zielführend, da manche Server mit dem neueren Standard noch ein Problem haben. Jedoch ist der gelieferte Film an sich Datenmüll und kann nicht angeschaut werden.
Auch eine Reduzierung der Bandbreite für den DL verhindert nicht das Problem. Und das Problem tritt neben MV auch mit wget, JDownloader und auch bei mir zusätzlich mit yt-dlp auf - unabhängig von der gewählten Auflösung. Von daher gesehen besteht aus Sicht von MV kein Grund weitere Änderungen vorzunehmen die nichts bewirken. Niemand kann hexen - aber man könnte auf Seiten der Sender mal die Fehler beheben.@DerReisende77 sagte in Fehlermeldung stream was reset:
@chf Die Server haben ein Problem und dies wird auch nicht durch unendliches Neuversuchen besser - denn die gelieferten Daten sind nach dem Reset Müll.
Das Problem sollte senderseitig gelöst werden. Welcher Sender mit diesem Problem bietet eine Downloadmöglichkeit an, um daran anzuknüpfen?
Meine mp4-Downloads mit wget und JD2 waren in Ordnung: Abspielbar, bitidentisch und die mp4-Box-Struktur war auch fehlerfrei.
-
@DerReisende77 sagte in Fehlermeldung stream was reset:
@chf Die Server haben ein Problem und dies wird auch nicht durch unendliches Neuversuchen besser - denn die gelieferten Daten sind nach dem Reset Müll.
Das Problem sollte senderseitig gelöst werden. Welcher Sender mit diesem Problem bietet eine Downloadmöglichkeit an, um daran anzuknüpfen?
Meine mp4-Downloads mit wget und JD2 waren in Ordnung: Abspielbar, bitidentisch und die mp4-Box-Struktur war auch fehlerfrei.
@Georg-J sagte in Fehlermeldung stream was reset:
@DerReisende77 sagte in Fehlermeldung stream was reset:
@chf Die Server haben ein Problem und dies wird auch nicht durch unendliches Neuversuchen besser - denn die gelieferten Daten sind nach dem Reset Müll.
[…]
Meine mp4-Downloads mit wget und JD2 waren in Ordnung: Abspielbar, bitidentisch und die mp4-Box-Struktur war auch fehlerfrei.Meine Versuche mit Mediathekview haben KEINEN Datenmüll ergeben: sobald die Fimle stückhenweise heruntergeladen waren, waren sie auch nutzbar; ich gehe mal davon aus, daß es mit den älteren Mediathekview-Versionen, die nicht auf HTTP 1.1 zurückfallen, anders sein könnte.
-
@chf Deine Analyse und Schlussfolgerungen sind falsch. Die Server haben ein Problem und dies wird auch nicht durch unendliches Neuversuchen besser - denn die gelieferten Daten sind nach dem Reset Müll. Der Wechsel von HTTP/2 auf 1.1. nach einem Fehler ist zielführend, da manche Server mit dem neueren Standard noch ein Problem haben. Jedoch ist der gelieferte Film an sich Datenmüll und kann nicht angeschaut werden.
Auch eine Reduzierung der Bandbreite für den DL verhindert nicht das Problem. Und das Problem tritt neben MV auch mit wget, JDownloader und auch bei mir zusätzlich mit yt-dlp auf - unabhängig von der gewählten Auflösung. Von daher gesehen besteht aus Sicht von MV kein Grund weitere Änderungen vorzunehmen die nichts bewirken. Niemand kann hexen - aber man könnte auf Seiten der Sender mal die Fehler beheben.@DerReisende77 sagte in Fehlermeldung stream was reset:
@chf Deine Analyse und Schlussfolgerungen sind falsch. Die Server haben ein Problem […] Der Wechsel von HTTP/2 auf 1.1. nach einem Fehler ist zielführend, da manche Server mit dem neueren Standard noch ein Problem haben. Jedoch ist der gelieferte Film an sich Datenmüll und kann nicht angeschaut werden.
Ich wollte auch nirgends so verstanden werden, daß ich das Übergehen zu 1.1 ablehne; im Gegenteil: das scheint zu bewirken, daß BEI MIR beim stückchenweisen Herunterladen mit Mediathekview KEIN MÜLL produziert wird – so lange mit HTTP 1.1 ab der letzten Abbruchstelle erneut zu laden, bis alles da ist, scheint hier stets zu funktionieren, ich habe keine Ausnahme finden können. Insoweit kann ich keinen Fehler in meinen Schlußfolgerungen erkennen; das Server-Problem zu beheben wäre sicher die erste Wahl, darauf zu warten könnte indes lange dauern und da es in der Vergangenheit schon Sender gegeben hat. die Mediathekview regelrecht boykottieren, weiß ich nicht, inwieweit es sinnvoll wäre, da beim BR vorzusprechen. Bisher habe ich nur bei Funk-Videos explizite Aufforderungen gesehen, die Beiträge herunterzuladen, sonst setzt „alle Welt“ auf „Streaming“. Solange ich also keine nennenswerte Anzahl von Gegenbeispielen sehe, wo der stückchenweise geladene Film am Ende Dattenmüll ist, sehe ich „ewige“ Wiederholungsversuche als gangbaren Weg an. Bei Fehlern im Programmen oder deren Zusammenspiel kommt es auf Nutzer-Sicht auch NIE darauf an, wer die Schuld trägt: es sieht so aus, als wäre es ein Mediathekview-Problem, weil’s anscheinend mit dem Browser geht, also wird es als ein solches gesehen und davon abgesehen führt das Herumhacken auf der Frage, welche Seite den Fehler zu beheben hätte, oft genug dazu, daß es niemand macht und somit der Fehler einfach bleibt. Fast immer geht das auf Kosten des schwächeren quelloffenen Projekts. Kann man sich drüber aufregen, ist aber so.
-
@DerReisende77 sagte in Fehlermeldung stream was reset:
@chf Deine Analyse und Schlussfolgerungen sind falsch. Die Server haben ein Problem […] Der Wechsel von HTTP/2 auf 1.1. nach einem Fehler ist zielführend, da manche Server mit dem neueren Standard noch ein Problem haben. Jedoch ist der gelieferte Film an sich Datenmüll und kann nicht angeschaut werden.
Ich wollte auch nirgends so verstanden werden, daß ich das Übergehen zu 1.1 ablehne; im Gegenteil: das scheint zu bewirken, daß BEI MIR beim stückchenweisen Herunterladen mit Mediathekview KEIN MÜLL produziert wird – so lange mit HTTP 1.1 ab der letzten Abbruchstelle erneut zu laden, bis alles da ist, scheint hier stets zu funktionieren, ich habe keine Ausnahme finden können. Insoweit kann ich keinen Fehler in meinen Schlußfolgerungen erkennen; das Server-Problem zu beheben wäre sicher die erste Wahl, darauf zu warten könnte indes lange dauern und da es in der Vergangenheit schon Sender gegeben hat. die Mediathekview regelrecht boykottieren, weiß ich nicht, inwieweit es sinnvoll wäre, da beim BR vorzusprechen. Bisher habe ich nur bei Funk-Videos explizite Aufforderungen gesehen, die Beiträge herunterzuladen, sonst setzt „alle Welt“ auf „Streaming“. Solange ich also keine nennenswerte Anzahl von Gegenbeispielen sehe, wo der stückchenweise geladene Film am Ende Dattenmüll ist, sehe ich „ewige“ Wiederholungsversuche als gangbaren Weg an. Bei Fehlern im Programmen oder deren Zusammenspiel kommt es auf Nutzer-Sicht auch NIE darauf an, wer die Schuld trägt: es sieht so aus, als wäre es ein Mediathekview-Problem, weil’s anscheinend mit dem Browser geht, also wird es als ein solches gesehen und davon abgesehen führt das Herumhacken auf der Frage, welche Seite den Fehler zu beheben hätte, oft genug dazu, daß es niemand macht und somit der Fehler einfach bleibt. Fast immer geht das auf Kosten des schwächeren quelloffenen Projekts. Kann man sich drüber aufregen, ist aber so.
sagte in Fehlermeldung stream was reset:
@DerReisende77 sagte in Fehlermeldung stream was reset:
@chf Deine Analyse und Schlussfolgerungen sind falsch. Die Server haben ein Problem […] Der Wechsel von HTTP/2 auf 1.1. nach einem Fehler ist zielführend, da manche Server mit dem neueren Standard noch ein Problem haben. Jedoch ist der gelieferte Film an sich Datenmüll und kann nicht angeschaut werden.
Ich wollte auch nirgends so verstanden werden, daß ich das Übergehen zu 1.1 ablehne; im Gegenteil: das scheint zu bewirken, daß BEI MIR beim stückchenweisen Herunterladen mit Mediathekview KEIN MÜLL produziert wird – so lange mit HTTP 1.1 ab der letzten Abbruchstelle erneut zu laden, bis alles da ist, scheint hier stets zu funktionieren, ich habe keine Ausnahme finden können. Insoweit kann ich keinen Fehler in meinen Schlußfolgerungen erkennen; das Server-Problem zu beheben wäre sicher die erste Wahl, darauf zu warten könnte indes lange dauern und da es in der Vergangenheit schon Sender gegeben hat. die Mediathekview regelrecht boykottieren, weiß ich nicht, inwieweit es sinnvoll wäre, da beim BR vorzusprechen. Bisher habe ich nur bei Funk-Videos explizite Aufforderungen gesehen, die Beiträge herunterzuladen, sonst setzt „alle Welt“ auf „Streaming“. Solange ich also keine nennenswerte Anzahl von Gegenbeispielen sehe, wo der stückchenweise geladene Film am Ende Dattenmüll ist, sehe ich „ewige“ (*) Wiederholungsversuche als gangbaren Weg an. Bei Fehlern in Programmen oder deren Zusammenspiel kommt es aus Nutzer-Sicht auch NIE darauf an, wer die Schuld trägt: es sieht so aus, als wäre es ein Mediathekview-Problem, weil’s anscheinend mit dem Browser geht, also wird es als ein solches gesehen und davon abgesehen führt das Herumhacken auf der Frage, welche Seite den Fehler zu beheben hätte, oft genug dazu, daß es niemand macht und somit der Fehler einfach bleibt. Fast immer geht das auf Kosten des schwächeren quelloffenen Projekts. Kann man sich drüber aufregen, ist aber so.
(*) Man kann’s ja schlau genug implementieren: wenn die Datei gar nicht wächst, trotzdem aufgeben, nicht über das voraussichtliche Ende hinaus versuchen,…
