– Regelmäßige, geplante Offline-Aufnahmen mit nextPVR, die in einem Ordner gespeichert werden
– MCEBuddy überwacht diesen Ordner und konvertiert neue Aufnahmen, wobei Werbung mit Comskip herausgeschnitten wird; anschließend wird die Originaldatei in einen anderen Ordner archiviert.
– Die konvertierte Datei landet in einem weiteren Ordner, auf den Plex zugreift.
Ich wohne jedoch in einem Empfangsgebiet mit schwachem Signal. Meistens ist die Empfangsqualität ausreichend, um eine ansehbare Aufnahme zu erhalten, auch wenn es hin und wieder Aussetzer oder Glitches gibt. Das muss ich akzeptieren, wo ich wohne.
Diese Glitches führen jedoch manchmal dazu, dass MCEBuddy die Aufnahme nicht erfolgreich verarbeiten kann, obwohl die Originaldatei (mit Werbung) meist problemlos manuell in Plex’ Ordner verschoben und dort abgespielt werden kann.
Das Problem: Wenn MCEBuddy eine Konvertierung nicht beenden kann, versucht es unendlich oft. Lasse ich den PC unbeaufsichtigt, konvertiert er endlos ein Backlog von Dateien, wobei die Festplatte durchgehend läuft. In den vier Jahren, die ich diesen Workflow nutze, sind bereits zwei Festplatten verschlissen. (MCEBuddy/Plex laufen glücklicherweise auf einer sekundären internen Festplatte.)
Gibt es eine Möglichkeit, MCEBuddy so einzustellen, dass es nicht immer wieder neu startet – dass bei einem fehlgeschlagenen Konvertierungsversuch einfach bei „fehlgeschlagen“ stehen bleibt, statt endlos weiterzuprobieren?
Es hängt davon ab, welcher Teil der Konvertierung fehlschlägt.
Falls das Remuxen fehlschlägt: MCEBuddy versucht, das Remuxen mit unterschiedlichen Parametern 4-mal durchzuführen. Diese sind in der Datei mcebuddy.conf unter dem Abschnitt FFMpegBackupRemux definiert, und Sie können den Unterschied zwischen jedem Versuch sehen (beginnt mit Transkodierung und endet schließlich mit Re-Codierung nach mpeg2)
Falls die Konvertierung fehlschlägt: Die Anzahl der Wiederholversuche hängt davon ab, wie Ihr Profil in profile.conf eingerichtet ist. Die meisten Profile verfügen über 3 Backups im Abschnitt order. Handbrake, Ffmpeg und Mencoder. Wenn ein Encoder fehlschlägt, greift das System auf den nächsten Encoder zurück usw. Es sollte also nach 3 Versuchen stoppen.
Es wird NIEMALS eine unendliche Anzahl von Versuchen geben, es ist im Wesentlichen durch Ihre oben genannte Konfiguration definiert. Sie können es also anpassen, z. B. Zeilen im Abschnitt FFMpegBackupRemux entfernen (oder weitere hinzufügen), falls das Remuxen fehlschlägt, oder Encoder entfernen, die Sie nicht im Profil unter dem Befehl order wünschen
Das Konvertierungsprotokoll zeigt, was fehlschlägt
Hier ist ein Ordner mit Protokolldateien, die das Problem zeigen (komprimierte ZIP-Datei).
Der Ordner enthält 77 Protokoll-Einträge, bei denen MCEBuddy sich alle 10-15 Minuten wiederholte, von 9:55 Uhr am 19.06.2017 bis die Schleife durch manuelles Verschieben der Aufnahme in einen anderen Ordner um etwa 07:27 Uhr am 20.06.2017 gestoppt wurde.
Können Sie die Original-TS-Datei auf den MCEBuddy-Uploadserver hochladen, damit wir sie analysieren können? Dies ist eine Problemdatei mit defekten Untertiteln, und wir möchten sehen, ob wir eine Lösung für fehlerhafte Untertitel anbieten können.
Danke für die Logs. Das unterscheidet sich von dem, was ich über Fallback-Konvertierungen gepostet hatte. Es sieht so aus, als würde die Engine die gesamte Konvertierung neu starten, was nicht passieren sollte.
Ich brauche die mcebuddy.log-Datei – dieses Log zeigt, warum die Engine die Konvertierung jedes Mal von Grund auf neu startet.
Ich lade gerade alles hoch. Es wird etwa 20 Minuten dauern, bis es abgeschlossen ist, dann solltest du die mcebuddy.log-Datei, die ursprüngliche .ts-Datei sowie die einzelnen Episoden-Logs haben, die zuvor gesendet wurden.
Okay, danke für die Logs und Beispieldateien. Lass mich zwei Punkte, die du angesprochen hast, klären:
Wenn deine Videoaufnahme beschädigt ist, schlägt die Untertitel-Extraktion fehl und auch die Konvertierung – das ist beabsichtigt. Die Idee dahinter ist: Wenn irgendetwas „fehlschlägt“, soll der Benutzer informiert werden – insbesondere, weil du eventuell „Original löschen“ oder andere gravierende Einstellungen aktiviert hast, die negative Auswirkungen haben könnten. Daher wird bei jedem „Fehler“ die Konvertierung bewusst abgebrochen. Du kannst diese Dateien später manuell neu konvertieren oder eine Option aktivieren, fehlgeschlagene Dateien in einen neuen Ordner zu verschieben und sie anschließend mit einer separaten Überwachungs- und Konvertierungsaufgabe erneut bearbeiten (z. B. ohne Untertitel-Extraktion). Ziel ist es, dem Benutzer die Kontrolle zu geben und Regeln für Ausnahmen zu definieren, anstatt Annahmen zu treffen.
Zu deinem Hauptproblem: Die endlose Konvertierungs-Schleife. Das Problem liegt in deiner MCEBuddy-Konfiguration. Du hast MCEBuddy buchstäblich dazu aufgefordert, deine Dateien – sowohl konvertierte als auch Originaldateien – unendlich oft zu überwachen. Siehe diese Konfiguration aus den Logs: Ich habe die Einstellungen hervorgehoben, bei denen deine Überwachungsaufgabe (Experteneinstellungen) so konfiguriert ist, dass Dateien endlos neu verarbeitet werden. AUßERDEM: Dein Archiv-Ordnerpfad ist ungültig, dir fehlt ein Slash \\ nach E:. Da deine Originaldatei bereits im Archiv-Ordner existiert, wird sie nicht verschoben – und durch deine Konfiguration hast du MCEBuddy angewiesen, jede Datei im Überwachungsordner unendlich oft neu zu konvertieren, auch wenn sie bereits konvertiert wurde (in deinem Fall wurde sie konvertiert, konnte aber aus dem genannten Grund nicht ins Archiv verschoben werden).
MONITOR TASK OPTIONS ==>
Task → Windows Default
Search Path → E:\Recorded TV
Monitor Delete Original → False
Monitor Archive Original → True Monitor Archive Folder → E:MCEBuddy2x\MCEBuddyArchive ← Fehlender \\ nach E:
Monitor SubDirectories → True Monitor Converted Files → True ← MCEBuddy soll konvertierte Dateien erneut konvertieren (warum??) ReMonitor Recorded Files → True ← MCEBuddy soll Originalaufnahmen, die bereits erfolgreich konvertiert wurden, erneut konvertieren – das ist der Grund für die Endlosschleife (warum??)
EDIT: In der nächsten Version wird das Standardverhalten für „Archiv“ und „Fehlgeschlagen“ geändert: Vorhandene Dateien werden überschrieben, damit solche Endlosschleifen künftig vermieden werden.