Fehlermeldung stream was reset

[CHF]

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.

[Georg-J]

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 0 url

[CHF]

Ich glaube inzwischen, es sind 2 unterschiedliche Fehler, der 2. könnte aber mit dem Versuch zusammenhängen, den 1. zu beheben.

[CHF]

@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 geladen

Damit 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.

[MenchenSued]

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.

[CHF]

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.

[CHF]

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“.

[mac-christian]

@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.

[MenchenSued]

@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.

[CHF]

Ä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”.

[Georg-J]

@CHF Du hast Recht. Ich habe das vielleicht falsch interpretiert. Während wget nach dem Statuscode 2 MiB herunterlädt und es wiederholt versucht, macht wget2 (ggf. nach den 2 MiB) keinen Wiederholungsversuch.