Was tun bei einem Programm-Crash ?

[ted]

Die letzte Beta crasht am Ende eines viele Stunden dauernden Kodiervorgangs. Reicht es, euch das Log zuzusenden oder braucht ihr auch die MKV? Was, wenn die MKV ein Riesending ist?

Ich frage, damit ich das nächste mal weiß, was zu tun ist. Die momentane MKV möchte ich nicht noch einmal laufen lassen, dauert mir zu lange. Mit der Avidemux-Release-Version lief es gerade mit ultrafast durch, da kam am Ende nur eine Fehlermeldung, dass irgendein Seek nicht gemacht werden konnte. Ich nehme an, dass sich die Meldung nur auf die Anzeige bezieht, denn das Resultat scheint in Ordnung zu sein. Jetzt lasse ich es wie üblich nochmal mit veryslow laufen. (Seek-Error am Ende einer Kodierung kommt auch bei den Betas öfter mal)

[eumagga0x2a]

Die letzte Beta crasht am Ende eines viele Stunden dauernden Kodiervorgangs. Reicht es, euch das Log zuzusenden oder braucht ihr auch die MKV?

Das weiß man nachdem man das Log gesehen hat.

Was, wenn die MKV ein Riesending ist?

WeTransfer akzeptiert Samples bis 2 GiB Größe. Wenn die Datei noch größer ist, muss man dann hoffen, dass sich das Problem bald auch mit einem anderen, kleineren Sample reproduzieren lässt.

Mit der Avidemux-Release-Version lief es gerade mit ultrafast durch, da kam am Ende nur eine Fehlermeldung, dass irgendein Seek nicht gemacht werden konnte.

Ja, Avidemux spult nach getaner Arbeit zurück zur Stelle, auf der Wiedergabe zuletzt gestoppt wurde. Wenn dies fehlschlägt, deutet dies schon auf einen Defekt der Input-Datei hin.

Ich nehme an, dass sich die Meldung nur auf die Anzeige bezieht, denn das Resultat scheint in Ordnung zu sein.

Die problematische Stelle könnte im Ergebnis dann schlicht übersprungen worden sein. Es kann auch sein, dass das Video ein H.264-Video ohne IDR-Frames ist (Keyframes sind dann Recovery-Frames, keine vollen IDR, so dass der Zähler an solchen Frames weiterläuft), das auf die Art und Weise geschnitten wurde, die FFmpeg nicht schmeckt (nämlich, wenn der Zähler an der Schnittstelle einen Sprung zurück macht). Die letzten Releases von Avidemux warnen vor solchen inkompatiblen Schnittpunkten.

[ted]

Danke für die Infos.
Mit der MKV stimmt tatsächlich was nicht, auch ein anderes Video-Programm crasht bei 59%. Das dürfte auch genau die Stelle sein, an dem Avidemux crasht. Was wirklich fehlt: ein MKV-Reparatur-Tool, das eine MKV in ein absolut korrektes Format bringt. Die wenigen Tools auf dem Markt funktionieren nicht besonders gut, ich glaube, ich habe sie alle getestet. Ich habe den Author von MKV Toolnix angeschrieben, ob er als bester Kenner des MKV-Formats ein solches Tool schreiben könnte. Das Tool übernimmt nur die allernotwendigsten Daten aus der MKV und versucht alles andere zu berechnen. Er antwortete ausführlich und freundlich, sowas sei Monate an Arbeit und dazu hätte er keine Lust. Kann ich nachvollziehen. Wenn ein solches Tool auf dem Markt wäre, würde ich zu allererst jede MKV damit laufen lassen, egal ob sie Probleme macht oder nicht. Gefühlt macht bei mir die Hälfte aller MKVs, die bei mir auf der Platte landen, Probleme. Da kommt man dann nur noch mit Tricks und einer ganzen Pallette an verschiedenen Video-Progs weiter, wenn auch nicht immer. Dann ab in den Müll damit.

[eumagga0x2a]

Darf ich bitte zuerst das Log sehen?

Mit der MKV stimmt tatsächlich was nicht, auch ein anderes Video-Programm crasht bei 59%. Das dürfte auch genau die Stelle sein, an dem Avidemux crasht.

Kann sein, muss aber nicht.

Dann ab in den Müll damit.

Bitte nicht! Zuerst sollten wir die Ursache für den Absturz eingrenzen.

[ted]

Wie ganz oben geschrieben, lief die Avidemux-Release-Version mit ultrafast durch, nur ein Seek-Meldung wurde angezeigt. Mit der selben PY, aber mit veryslow lief die Release-Version jetzt auch durch und sogar ohne Seek-Fehlermeldung.

>> Bitte nicht! Zuerst sollten wir die Ursache für den Absturz eingrenzen.

Die MKV hat über 5 oder 6 GB und ein Lauf mit der Avidemux-Beta dauert 10 Stunden oder so. Tut mit leid, aber das ist mir zu aufwendig. Wenn ein Crash mit der Beta mit einer kleineren MKV noch einmal auftritt, kann ich sie euch zusammen mit der PY zukommen lassen. Zuerst die LOG und, falls notwendig, die MKV.

(Zur Beta muss ich eh wechseln, die Release hat Probleme mit der Priority. Wenn ich in der Beta auf 'unter normal' stelle, kann ich noch andere Arbeiten erledigen. Bei der Release geht dies sogar mit Prio=niedrig nur sehr schlecht, der (alte) Rechner reagiert extrem träge. Im Taskmanager steht korrekt 'niedrig', trotzdem verwendet Avidemux über 90% CPU. Vielleicht muss ich die CPU-Anzahl auf 1 setzen. Werde es das nächste mal testen.)

[eumagga0x2a]

Ich habe so verstanden, dass das admlog.txt vom Absturz gesichert ist und jederzeit an eine Antwort angehängt werden kann. War das ein Missverständnis?

Priorität hat nichts mit CPU-Last zu tun. Wenn die CPU gerade nichts anderes, dringenderes zu tun hat, kann auch ein Prozess mit sehr niedriger Priorität mit vollem Recht 100% CPU beanspruchen und auch bekommen.

[ted]

Tut mir leid, da habe ich mich wohl missverständlich ausgedrückt. Die Logdatei habe ich leider nicht gesichert, hätte ich machen sollen. Wird die admlog.txt bei jedem Crash oder bei jedem Lauf angelegt und ist sie dann neu oder wird angehängt? In der admlog.txt stehen jetzt nur 45 Zeilen. Vielleicht wurde sie überschrieben, als ich vorhin wieder die Beta über die Release installiert habe?

Wenn das nächste mal ein Crash passiert, werden ich die admlog.txt hier gleich posten. Wenn es dann notwendig wird, auch die zugehörige Eingabedatei, wenn nicht zu groß. 2GB sind für Videos allerdings nicht gerade viel.

> Priorität hat nichts mit CPU-Last zu tun.

Die Priorität legt fest, wieviel CPU-Rechenzeit ein Thread vom System anteilig zugeteilt bekommt, das ist mir schon klar. Ich schrieb bereits, dass die ganze Kiste in die Knie geht, wenn Avidemux-Release kodiert. Die CPU-Auslastung von avidemux.exe geht eben nicht runter, wenn ich z.B. ein anderes Programm mit normaler Prio starte. Die Last geht sogar auch dann nicht runter, wenn ich die Prio in Avidemux auf niedrig stelle. Mit der Beta gibt es dieses Problem überhaupt nicht, da gehen die CPU-Prozente sofort runter, sobald ein Programm mit höherer Priorität als Avidemux irgendwas bearbeitet. Bei einem anderen Videoprogramm (sehr Beta) hatte ich die Prio auf niedrig gestellt und konnte auch nichts mehr arbeiten, denn das Programm lief zwar mit niedrig, startete aber x264 mit hoch! Das ist bei Avidemux aber nicht so, die CPU-Auslastung wird direkt von avidemux.exe erzeugt. Wie gesagt: die Beta hat kein solchen Problem.

[eumagga0x2a]

Wird die admlog.txt bei jedem Crash oder bei jedem Lauf angelegt

Bei jedem Lauf. Nach einem Crash enthält sie mit etwas Glück die "letzten Worte" von Avidemux, die einen Hinweis auf die Ursache liefern können.

und ist sie dann neu

Immer neu. Bei jedem Avidemux-Start. Deswegen sollte man nach einem Crash immer zuerst die Spuren sichern, dann Avidemux neu starten.

Die CPU-Auslastung von avidemux.exe geht eben nicht runter, wenn ich z.B. ein anderes Programm mit normaler Prio starte. Die Last geht sogar auch dann nicht runter, wenn ich die Prio in Avidemux auf niedrig stelle. Mit der Beta gibt es dieses Problem überhaupt nicht, da gehen die CPU-Prozente sofort runter, sobald ein Programm mit höherer Priorität als Avidemux irgendwas bearbeitet.

Ich kann mir diese Beobachtung nicht wirklich erklären. Der letzte Nightly enthält zwar zwei kleine Änderungen am Code, der die aktuellen Prioritätsgruppe von Avidemux zu Beginn eines Neukodierung abfragt, aber in dem Zusammenhang dürften sie keine Rolle spielen.

Man könnte mehr herausfinden wenn es ein Archiv der älteren Builds gäbe.

[ted]

> Der letzte Nightly enthält zwar zwei kleine Änderungen am Code ...

Ein Hinweis: mit älteren Betas gab es auch nicht das beschriebene Problem. Der Effekt war so auffallend, dass es unnmöglich unbemerkt geblieben wäre. Vielleicht sollte die Release nicht über die Beta installiert werden, weil irgendwelche Files nur gut mit der Beta zusammenarbeiten? Kann ich mir aber nicht so ganz vorstellen, denn Avidemux zeigt "Downgrade Avidemux using previous settings (recommended)" an, weshalb ich davon ausgehe, dass auch die Downgrade-Probleme beachtet werden. Vielleicht stimmt auch nur mit meinem Rechner etwas nicht? Für mich ist erstmal wichtiger, dass die Beta funktioniert, was sie tut.

[eumagga0x2a]

Der Effekt war so auffallend, dass es unnmöglich unbemerkt geblieben wäre.

Doch, alles, was nicht von Nightly-Usern gemeldet wird, hat gute Chancen unbemerkt zu bleiben und sich im Release wiederzufinden. Das gilt besonders für den legacy-compat-Zweig, aus dem 32-bits-Nightlies und -Releases erstellt werden.

Vielleicht sollte die Release nicht über die Beta installiert werden, weil irgendwelche Files nur gut mit der Beta zusammenarbeiten?

Eine Neuinstallation in einen anderen Ordner würde die Frage klären, ob es mit irgendwelchen Altlasten zusammenhängt oder nicht.

Kann ich mir aber nicht so ganz vorstellen, denn Avidemux zeigt "Downgrade Avidemux using previous settings (recommended)" an, weshalb ich davon ausgehe, dass auch die Downgrade-Probleme beachtet werden.

Geziehlt überprüft das heutzutage beim NSIS-Installer, der für MinGW-Builds verwendet wird, glaube ich, niemand.

[ted]

>> Der Effekt war so auffallend, dass es unnmöglich unbemerkt geblieben wäre.

Edit:  Der Effekt war so auffallend, dass es unnmöglich nicht von mir unbemerkt geblieben wäre.

[ted]

Ich habe jetzt mal avidemux deinstalliert, alles auf dern Platte gesäubert und die Release-Version neu installiert. Der Effekt ist nicht mehr reproduzierbar, die CPU-Belastung durch avidemux.exe geht wie üblich zurück, sobald ein Programm mit höherer Priorität gestartet wird. Keine Ahnung, was der Grund für das genannte Problem bei mir war. Es war auch nicht nur kurz da und dann wieder weg, nein, es ging über die gesamte Kodierungsdateu von 7 Stunden oder sowas, egal wie ich die Prio für Avidemux gesetzt habe. Im Taskmanager war zu erkennen, dass die neue Prio jeweils angenommen worden ist, nur ging die CPU-Belastung durch avidemux.exe einfach nicht runter, wenn ein höher priviligierter Prozess gestartet wurde.

In Zukunft werden ich es immer so machen:
Egal ob up- oder downgrade: zuerst deinstallieren, Platte ggf. säubern, dann neu installieren.
Durch die Deinstallation gehen die Einstellung in appdate\roaming nicht verloren. Mal sehen, ob es notwendig ist, auch diese zu löschen.
Was ein wenig nervt beim Uninstall: es wird ein Reboot verlangt, obwohl nur im Temp-Ordner etwas zu löschen ist. Dazu habe ich andere Tools. Jetzt lösche ich in der Registry den Inhalt von PendingFileRenameOperations, geht auch.