Fehlermeldung stream was reset
-
@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,…
-
@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 sagte in Fehlermeldung stream was reset:
@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.
Ich nutze keine alte MV Version sondern die nightlies - ich baue die schließlich.
-
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,…
@CHF sagte in Fehlermeldung stream was reset:
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.
Ich weiß nicht wie Du zu der Annahme kommst das nach der “stream was reset” Fehlermeldung und dem erneuten starten MV weiterhin den DL mit HTTP1.1 macht ohne dass Du den Code verändert hast.
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.
Dann scheinst Du schon länger bei MV dabei zu sein als ich. Ich kenne seit 2008 keinen Sender der uns aktiv “boykottiert” hat abseits von legitimem bandwidth throttling weil einige Nutzer es übertreiben mussten.
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.
Solange ich bei mir keine nennenswerte Anzahl an erfolgreichen Downloads ohne Datenmüll sehe, sehe ich ewige Wiederholungsversuche als nicht-gangbaren Weg an. Desweiteren sollten diese Downloads dann auch alle wie auf den vorherigen Seiten gegenteilig beschrieben auch via wget, yt-dlp und JD2 funktionieren.
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.
Sorry, aber das ist ja so hanebüchen dass mir dazu nur folgendes einfällt: Ich als das schwächere Projekt kann damit leben, der Fehler wird bis zum Fix auf der einzig richtigen Seite nicht behoben.
(*) Man kann’s ja schlau genug implementieren: wenn die Datei gar nicht wächst, trotzdem aufgeben, nicht über das voraussichtliche Ende hinaus versuchen,…
Dazu musst Du nur die Klasse
mediathek.controller.starter.DirectHttpDownloadentsprechend bearbeiten. Als open-source-Projekt freuen wir uns über jeden getesteten Beitrag um Fehler zu beseitigen. Dir ist aber hoffentlich aufgefallen dass nach dem stream reset sich auch die gemeldete Dateigröße ändert und man nun entscheiden muss welche der beiden denn nun die richtige ist. -
@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 sagte: Solange Web-Browser-Nutzer aus welchem Grund auch immer nicht ebenfalls betroffen sind, dürfte den BR das nicht interessieren.
Gemäss diesem Thread sind diese Nutzer (MVW-Benutzer) sehr wohl auch betroffen, was du zu ignorieren scheinst. Und falls du die Benutzer in der BR-Mediathek meinst: Dort werden HLS-/DASH-Streams abgespielt, was nichts mit dem MP4-Direktdownloads zu tun hat, deren URL MV bereitstellt. Und da der BR prinzipiell überhaupt keinen Download in der Mediathek anbietet, dürfte das den BR tatsächlich überhaupt nicht interessieren (solange das Abspielen in der Mediathek funktioniert)…
