Sehr langsame Downloads und Fehler
-
@dadirnbocher: Das was ich weiter oben im Nachtrag beschrieben habe.
Danke für die Klarstellung.
@dadirnbocher sagte: Non-monotonous DTS in output stream 0:0; previous: 9000000, current: 9000000; changing to 9000001. This may result in incorrect timestamps in the output file.
Diese Meldungen sind nichts Neues und haben mit dem Videomaterial selbst zu tun. FFmpeg konstatiert halt nur, was Sache ist.
Die Fehlermeldung “fehlerhaft” kommt von MV 13.7, die wird nicht einfach von FFmpeg durchgereicht (FFmpeg liefert ja das auch gar nicht so). Und bei MV 13.6 und 13.0.6 gibt’s bei mir diese Fehlermeldung nicht (nur getestet an der besagten Sendung). Nochmals: Weshalb sollte das nun eine FFmpeg-Issue sein (auch wenn ich das mit den Zeitdifferenzen verstehe)?
@dadirnbocher: Als zusätzliche Dimension kommt dann dazu, dass MV offenbar mit 13.7. auf derartige Differenzen anders (sensibler) reagiert als in früheren Versionen.
Eben… (mal abgesehen davon, dass ich beim ORF mit älteren MV-Versionen noch nie Downloads mit der Meldung “fehlerhaft” hatte; muss aber nichts heissen, da ich selten beim ORF runterlade.)
Übrigens lassen sich die MV-Fehlerhaft-Meldungen mit “-loglevel error” vermeiden (okay, ist dann möglicherweise problematisch, wenn der DL “echt” fehlerhaft ist):
@dadirnbocher: Und genau das protokolliert MV 13.7. im Logfile
Da fällt mir gerade auf: Wo ist der Befehl “Protokolldatei erstellen”? Der fehlt bei mir im Hilfe-Menü in der Mac-Version von MV 13.7:
-
@ttl sagte in Sehr langsame Downloads und Fehler:
Hallo,
ich will nur einen spontanen Gedanken einwerfen:
Könnten abbrechende/aussetzende VPN-Verbindungen solche Fehler verursachen? Also das bei VPN ohne killswitch bei einzelnen Segmenten das GEO-Blocking wirksam wird?!
Ich benutze kein VPN und bei mir tritt der Fehler auf (macOS).
-
@styroll sagte in Sehr langsame Downloads und Fehler:
Da fällt mir gerade auf: Wo ist der Befehl “Protokolldatei erstellen”? Der fehlt bei mir im Hilfe-Menü in der Mac-Version von MV 13.7
Dieser Befehl wurde entfernt. Ich habe das in irgendeinem Commit gelesen und es wurde viel Zeit in die Umstellung auf einen neuen Logger investiert. Ich nehme an, dass derzeit alles in das Logfile geschrieben wird und kein Befehl mehr erforderlich ist. Zusätzlich gibt es jetzt noch den Parameter --enhanced-logging (mit einem oder zwei Strichen?), den sollte man aber mit Bedacht nutzen, denn der hat Auswirkungen auf die Geschwindigkeit.
-
In dem grossen Screenshot vom ffmpeg-Protokoll hat DaDirnbocher doch eigentlich dokumentiert, was geschehen ist:
Zwei Segmente - 8 und 9 - wurden wegen 403-Fehler nicht empfangen. Die fehlen dann im resultierenden Video, das deswegen entsprechend kuerzer ist. Wenn die Verluste weniger als 0,5% ausmachen, mosert die Software nicht. Bei einem kurzen Wetterbericht reicht es aber fuer eine Meldung.
Interessant finde ich, dass bei zwei Segmenten der Zugriff gesperrt ist (403) bei den restlichen aber (wie eigentlich erwartet) nicht. Das scheint mir ein Problem beim ORF zu sein. Ob das oefter vorkommt, ohne dass man das so explizit zu sehen bekommt?
-
Zwei Segmente - 8 und 9 - wurden wegen 403-Fehler nicht empfangen. Die fehlen dann im resultierenden Video, das deswegen entsprechend kuerzer ist
So, so, dann schau doch mal mit VLC diese 2 Segmente (8 und 9) an:
https://apasfiis.sf.apa.at/cms-worldwide_nas/_definst_/nas/cms-worldwide/online/2020-12-30_1920_sd_21_Wetter-Wien_____14076832__o__1124636815__s14826957_7__BLWHD_19191924P_19210001P_Q4A.mp4/media_8.ts https://apasfiis.sf.apa.at/cms-worldwide_nas/_definst_/nas/cms-worldwide/online/2020-12-30_1920_sd_21_Wetter-Wien_____14076832__o__1124636815__s14826957_7__BLWHD_19191924P_19210001P_Q4A.mp4/media_9.tsSind die jetzt bloss je 0.5 sec lang, um die Differenz von 1 Sekunde in der Totallänge der Sendung zu erklären?
Nein, eben, ist ja auch nicht anders zu erwarten, denn die Segmente sind rund 10 sec lang (steht auch so in der Chunklist):#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10, media_0.ts #EXTINF:10, media_1.ts #EXTINF:10, media_2.ts #EXTINF:10, media_3.ts #EXTINF:10, media_4.ts #EXTINF:10, media_5.ts #EXTINF:10, media_6.ts #EXTINF:10, media_7.ts #EXTINF:10, media_8.ts #EXTINF:10, media_9.ts #EXTINF:1, media_10.ts #EXT-X-ENDLIST10 Segmente (media_0 media_9) à 10 sec ergibt dann die Gesamtspielzeit von 100 sec oder eben 1 min 40 sec. Und das Segment 10 ist leer, wird aber als 1 sec lang deklariert:
https://apasfiis.sf.apa.at/cms-worldwide_nas/_definst_/nas/cms-worldwide/online/2020-12-30_1920_sd_21_Wetter-Wien_____14076832__o__1124636815__s14826957_7__BLWHD_19191924P_19210001P_Q4A.mp4/media_10.ts -
Hier wäre das nächste mit “fehlerhaft” markierte:
ORF ZIB 13:00 WetterIch verfolge was ihr schreibt komme aber ehrlich gesagt nicht ganz mit ob es seitens des ORF ein Problem gibt oder doch ffmpeg bei mir.
Wenn letzteres zutrifft müsste es dann nicht auch bei anderen Sendern auftreten ? -
@dxellas sagte in Sehr langsame Downloads und Fehler:
Hier wäre das nächste mit “fehlerhaft” markierte:
ORF ZIB 13:00 WetterWenn die ORF- oder SRF-Sendungen kürzer als 2 Min 30 sekunden sind, probier das runtergeladene File aus. Lässt es sich abspielen, ist alles gut, und “fehlerhaft” nur irrtümlich fehlerhaft.
-
Abspielbar ist es problemlos nur wie gesagt es wundert mich dass es überhaupt als fehlerhaft markiert wird.
Da nach Beispielen zur Analyse gefragt wurde habe ich auch dieses hinzugefügt.
Wenn keins mehr gewünscht wird werde ich mich nur zurückmelden wenn es wirklich Probleme beim Abspielen gibt. -
@dxellas sagte: Abspielbar ist es problemlos nur wie gesagt es wundert mich dass es überhaupt als fehlerhaft markiert wird.
Das habe ich ja im obigen Thread an einem konkreten Beispiel erklärt. Du kannst die Meldung ignorieren und wie schon mal gesagt, auch auf MV 13.6. zurückgehen: Da kriegst du die Meldung nicht.
-
Doch, bei mir erscheint auch mit der 13…6.0 der Fehler.
Sei’s drum. Ich ignoriere es solange die Sendungen ohne Probleme laufen. -
@dxellas sagte: Doch, bei mir erscheint auch mit der 13…6.0 der Fehler.
Ich hab jetzt mal – nach den Tests mit “Wetter Wien 30.12.2020” – auch noch die anderen von dir angegebenen Sendungen mit MV 13.6.0 runtergeladen:
@dxellas sagte: Habe noch zwei fehlerhafte vom ORF:
ZIB 17:00 Wetter 31.12.20
Wetter Wien 31.12.20
[…]
Hier wäre das nächste mit “fehlerhaft” markierte:
ORF ZIB 13:00 Wetter 3.1.2021Zumindest mit der macOS-Version von MV 13.6.0 gibt’s da nie eine Fehlermeldung…
Habe MediathekView-13.6.0-win32.zip geladen, entpackt
Die 32-bit-Version ist experimentell, vielleicht nicht gerade die beste Version zum Testen. Evtl. kannst du oder @DaDirnbocher mal die obigen Sendungen auch noch mit MV 13.6 testen (man kann ja MV in portabler Version starten, damit man mit separaten Einstellungen arbeiten kann).
-
Es ist die portable 13.6 mit der ich getestet habe. Wie gesagt, fehlerhaft.
-
@styroll sagte in Sehr langsame Downloads und Fehler:
Zumindest mit der macOS-Version von MV 13.6.0 gab’s da nie eine Fehlermeldung…
Hatte an meinem MacBook Air mit MV 13.6.0 auch nie Probleme.
Die Fehlermeldungen sind erst mit MV 13.7.0 aufgetreten. -
@dxellas sagte in Sehr langsame Downloads und Fehler:
Doch, bei mir erscheint auch mit der 13…6.0 der Fehler.
Es ist doch völlig egal. In dem Thread ist Dir jetzt mehrmals erklärt worden, dass man bei kurzen SRF-/ORF-Sendungen, wenn sie abspielbar sind, diese Fehlermeldung ignorieren kann.
Wenn die Fehlermeldung auch bei 13.6. kommt (und die Sendung abspielbar ist), kann man sie auch bei 13.6. ignorieren.
-
@styroll sagte in Sehr langsame Downloads und Fehler:
@dxellas sagte: Abspielbar ist es problemlos nur wie gesagt es wundert mich dass es überhaupt als fehlerhaft markiert wird.
Das habe ich ja im obigen Thread an einem konkreten Beispiel erklärt. Du kannst die Meldung ignorieren und wie schon mal gesagt, auch auf MV 13.6. zurückgehen: Da kriegst du die Meldung nicht.
styroll schrieb das hier:
“Du kannst die Meldung ignorieren und wie schon mal gesagt, auch auf MV 13.6. zurückgehen: Da kriegst du die Meldung nicht.”
Einzig deswegen habe ich es erwähnt.
Und ich habe auch mehrmals geschrieben dass es mir egal ist solange die Videos problemlos laufen.
Wenn jemand die Ursache findet wäre es schön davon hier zu lesen ansonsten ist für mich der Fall abgeschlossen.Danke an alle Beteiligten.
-
@dadirnbocher sagte: Wenn die Fehlermeldung auch bei 13.6. kommt
Um zu überprüfen, ob das Problem eine Windows-only-Issue ist, wäre es eben hilfreich, wenn du das Auftreten der MV-Fehlermeldung auf deinem System mit MV 13.6.0 testen könntest. Bisher bezogen sich deine Aussagen nämlich nur auf die FFmpeg-Fehlermeldungen:
@DaDirnbocher sagte: Da dürfte es ein Problem beim ORF geben. Egal ob ich mit 13.3, 13.6 oder 13.7 lade, es gibt immer diese (ffmpeg=)Meldung:
Und wie gesagt: Erfahrungen (von @dxellas) auf der Basis der experimentellen 32-bit-Version von MV 13.6 sind nur bedingt hilfreich.
@DaDirnbocher sagte: @dxellas Es ist doch völlig egal. In dem Thread ist Dir jetzt mehrmals erklärt worden, dass man bei kurzen SRF-/ORF-Sendungen, wenn sie abspielbar sind, diese Fehlermeldung ignorieren kann.
Na ja, abspielbar werden “fehlerhafte” Sendungen mit einem Player wie VLC wohl immer sein, selbst wenn dann mal echt Segmente fehlen. Das ist nicht der Punkt.
-
@styroll Ganz ehrlich, ich versteh schon einige Zeit nimmer. worums eigentlich noch geht.
ffmpeg liefert vorm Download eine “Duration” und während/nach Download eine “time”.
MV vergleicht, wenn ich den Source richtig verstehe, diese beiden Werte, und meldet einen Download als fehlerhaft, wenn die (End-)time weniger als 99,5% der (anfänglichen)Duration ist. Und schreibt das auch so ins Log:
Download fehlgeschlagen: 99,5% wurden nicht erreicht
Diese Fehlermeldung kommt - wenn ich das richtig sehe - mit der aktuellen MV Version 13.7 sowohl unter Windows als auch unter MacOS.
In den konkreten Fällen handelt es sich halt um sehr kurze Sendungen (tw unter einer Minute, tw. etwas über einer Minute), so dass eine Differenz, die unter einer Sekunde ausmacht, trotzdem mehr als 0,5% ausmachen kann und daher solche kurzen Sendungen als irrtümlich fehlerhaft erkannt werden.
Wenns jetzt Feststellungen gibt, dass die Meldung unter 13.6 nicht gekommen ist/nicht kommt, liegt das vielleicht daran (ich weiss es nicht), dass irgendwas am Source geändert wurde, das kann wohl am besten @DerReisende77 beurteilen.
-
@dadirnbocher Im Bereich ffmpeg/Downloads hat sich nichts geändert. Alle Änderungen dokumentiere ich mittlerweile direkt im CHANGELOG und davon ist nichts erwähnt.
-
@dadirnbocher sagte: Wenns jetzt Feststellungen gibt, dass die Meldung unter 13.6 nicht gekommen ist/nicht kommt
Genau darum geht es: Ob du das als Windows-User mit MV 13.6.0 anhand der genannten Sendungen bestätigen kannst oder nicht. Hab ich ja oben schon geschrieben:
@styroll sagte: Um zu überprüfen, ob das Problem eine Windows-only-Issue ist, wäre es eben hilfreich, wenn du das Auftreten der MV-Fehlermeldung auf deinem System mit MV 13.6.0 testen könntest.
Es geht ja zuerst mal ums “ob”, bevor man zum “warum” (MV 13.6 vs. 13.7) kommen kann.
-
@styroll Interessanter ist - in meinen Augen doch - ob
a) die Zeitdifferenz jetzt “eh ok” ist (und der Download irrtümlich fehlerhaft gekennzeichet wird) oder es doch ein fehlerhafter Download ist (der vielleicht bisher nicht als solcher erkannt wurde) und
b) wenn es irrtümlich fehlerhaft gekennzeichet wird, ob es in zukünftigen Versionen eine Anpassung der Prüfung geben wird.Insofern versteh immer noch nicht, was der “Test” bringen soll. Dass die 13.6 anders reagiert, wurde ausserdem auch bereits festgestellt.
Aber gut, wenns Dir wichtig ist. Bei mir wird “Wetter Wien” in 13.6 als ok gekennzeichnet. Die Angaben von ffmpeg aus 13.6 und ffmpeg aus 13.7. (duration, time) sind ident, wie auch die Filegrößen (auf Byte) der jeweils runtergeladenen Files.
