Optionale Einstellung zum Entfernen gelöschter Dateien aus dem Verlauf beim Verarbeiten von "Sync converted files"

Fehler / Funktionswünsche New Features
1

MCEBuddy Version: 2.7.1

Betriebssystem: Windows 10 IoT Enterprise LTSC 2021 x64

Zusammenfassung des Vorschlags: Ich verwende die Option „General Settings → Sync converted files“, um konvertierte Dateien auf meinem Dateiserver mit den Quelldateien auf meinem Medienlaufwerk zu synchronisieren. In meiner Bibliothek gibt es aufgrund von Hinzufügen, Verschieben und Löschen von Quelldateien viel Churn. Wenn eine Quelldatei gelöscht wird, löscht MCEBuddy die konvertierten Dateien – das ist eine großartige Funktion und passt perfekt in meinen Workflow. Es gibt jedoch einige Nachteile der aktuellen Implementierung:

  1. Der Konvertierungsauftrag bleibt unbegrenzt in der Verlaufsdatei, wodurch diese immer größer wird.
  2. Das Parsen der Verlaufsdatei wird mit wachsendem Medien‑Churn wegen Punkt 1 immer langsamer.
  3. Das Scannen wird mit wachsendem Medien‑Churn wegen Punkt 1 immer langsamer.
  4. Wenn eine Quelldatei später mit demselben Namen und Pfad wieder eingeführt wird, ignoriert MCEBuddy sie unbegrenzt, weil sie bereits in der Verlaufsdatei existiert (Punkt 1).

Mit aktivierter Option „Remove deleted files from history“ würde beim Löschen einer Quelldatei die konvertierte Datei automatisch gelöscht (wie bisher) und anschließend sowohl die Quelle‑ als auch die konvertierte Datei aus der Verlaufsdatei entfernt, sodass sie nicht mehr verfolgt werden. Nebenbemerkung: Damit würde die Verlaufsdatei zu einer Datenbank aktuell verfolgter Dateien werden und nicht mehr zu einer historischen Aufzeichnung.

Mir ist bewusst, dass ich „Expert Settings → Re‑monitor recorded videos“ aktivieren kann, damit MCEBuddy die Informationen der Quelldatei in der Verlaufsdatei ignoriert und sie erneut konvertiert. Das Problem ist, dass dies bei jedem Scan zu einer Neukonvertierung führt, wenn ich nicht gleichzeitig „Expert Settings → Delete original file“ oder „Expert Settings → Archive original file“ auswähle, was meinen Anwendungsfall zerstört, also keine Lösung ist. Zudem löst es die anderen Probleme der wachsenden Verlaufsdatei nicht.

Derzeit umgehe ich dieses Verhalten mit einem selbst geschriebenen Skript, das nachts läuft und die Verlaufsdatei „säubert“. Das Skript parst mcebuddy.log und sucht nach dem Text “[source] is stopped being monitored since it has been deleted”. Für jede Instanz extrahiert es den Quellpfad aus dem Log‑Eintrag und verwendet diesen, um sowohl den Eintrag der konvertierten Datei als auch den Eintrag der Quelldatei aus der Verlaufsdatei zu löschen. Das funktioniert bemerkenswert gut und löst alle oben genannten Probleme, hat jedoch einige Nachteile:

  1. „System Settings → Logging Level“ muss auf Debug gesetzt werden, was mehr Festplatten‑Churn verursacht und MCEBuddy leicht verlangsamt.
  2. „System Settings → Logfile age“ muss auf einen hohen Wert gesetzt werden, um zu verhindern, dass die Einträge gelöschter Dateien vor der nächtlichen Skriptausführung aus dem Log entfernt werden, wenn viel Medien‑Churn stattfindet. Das bedeutet, dass das nächtliche Skript mehr zu parsen hat.
  3. Wenn eine Quelldatei später mit demselben Namen und Pfad wieder eingeführt wird, ignoriert MCEBuddy sie bis zum nächsten Tag (nach dem nächtlichen Skriptlauf).
  4. Es ist ein weiterer Aufwand, den ich warten muss.

Wenn MCEBuddy die vorgeschlagene Funktionalität nativ unterstützen könnte, indem es die Einträge aus dem Verlauf entfernt, sobald die Quelldatei gelöscht wird, würde das das Problem effizienter lösen und wäre für mich sehr hilfreich.

Danke fürs Lesen!