Neuer Scan über die CLI wird ignoriert, wenn bereits ein Scan läuft

Ich verwende hier MCEBuddy 2.5.7 Premium. Ich habe MCEBuddy so konfiguriert, dass es eine SMB1-Dateifreigabe auf einem separaten Windows-Dateiserver nach umzuwandelnden Dateien durchsucht. (Ja, ich weiß, dass SMB1 unsicher ist, aber ich kann das im Moment nicht ändern.) Das Scannen eines großen Verzeichnisbaums über SMB1 ist nicht schnell, und meine Scans dauerten oft etwa 10 Minuten. Bei der standardmäßigen Abrufperiode von 5 Minuten war der Scan-Datenverkehr konstant und erzeugte eine Menge unnötigen Netzwerkverkehr sowie Festplatten-/CPU-Aktivität. Anstatt das Scan-Intervall einfach nur zu erhöhen, habe ich ein paar Skripte zusammengeschrieben, um das Ganze effizienter zu machen.

Jetzt läuft auf dem Windows-Dateiserver ein Skript, das die betreffenden Verzeichnisse über die Win32-API für Verzeichnisdienste überwacht. Da es ereignisgesteuert und nicht polling-basiert ist, muss mein Skript nie abfragen, ob sich Dateien geändert haben; stattdessen informiert das Betriebssystem mein Skript sofort, sobald etwas passiert. Wenn sich etwas im Baum ändert, legt mein Skript eine Marker-Datei in der Freigabe ab. (Es nutzt auch etwas Hysterese, um mehrere aufeinanderfolgende Änderungen als eine einzige zu behandeln und eine angemessene Zeit zu warten, bis keine Änderungen mehr auftreten.) Ein zweites Skript auf dem MCEBuddy-Rechner prüft alle 60 Sekunden, ob diese eine Marker-Datei existiert. Wenn sie vorhanden ist, löscht es die Marker-Datei und initiiert einen Rescan in MCEBuddy durch Ausführen von „MCEBuddy.UserCLI.exe --command=engine --action=rescan“. Die tatsächliche Abrufperiode von MCEBuddy ist auf 1 Woche (604800 Sekunden) gesetzt, um alles abzudecken, was das Skript aus irgendeinem Grund übersehen haben könnte. Das löst mein ursprüngliches Performance-Problem, denn statt ständig Tausende von Dateien über SMB1 zu scannen, führt der MCEBuddy-Rechner nur noch ein „if exist“ auf eine einzelne Datei aus, und MCEBuddy macht nur dann einen vollständigen Scan, wenn es nötig ist.

Es gibt jedoch ein kleines Problem, das durch die Art und Weise entsteht, wie MCEBuddy mit „MCEBuddy.UserCLI.exe --command=engine --action=rescan“ umgeht, falls bereits ein Scan läuft.

Was ich erwarte, dass MCEBuddy tut:

  1. Den aktuellen Scan abbrechen und von vorne beginnen.
    – ODER –
  2. (Bis zu 1) Rescan-Anfrage(n) in eine Warteschlange packen, bis der aktuelle Scan fertig ist, dann erneut scannen.

Was MCEBuddy tatsächlich tut:
Die Rescan-Anfrage wird angenommen, aber ignoriert, und Erfolg gemeldet:
MCEBuddy.UserCLI trying to connect to Engine localhost on Port 23332
MCEBuddy.UserCLI successfully connected to MCEBuddy engine
MCEBuddy.UserCLI processing command engine
MCEBuddy.UserCLI rescanning monitor locations and logs
MCEBuddy.UserCLI Successful!!

Das führt dazu, dass Änderungen verloren gehen, wenn während eines laufenden MCEBuddy-Scans eine Änderung auftritt.

Der Clou ist: Ich könnte das leicht umgehen, wenn ich programmatisch erfahren könnte, ob MCEBuddy gerade scannt – aber das geht nicht. Wenn sich nur eine dieser kleinen Dinge ändern würde, könnte ich damit leben:

  • Wenn MCEBuddy eines der oben genannten Verhalten zeigen würde (bevorzugte Lösung), müsste ich nichts weiter tun.
  • Wenn MCEBuddy.UserCLI.exe einen Fehler statt Erfolg zurückgeben würde, könnte mein Skript den Rescan später erneut versuchen.
  • Wenn MCEBuddy.UserCLI.exe eine Möglichkeit hätte, die Engine abzufragen, ob gerade ein Scan läuft, könnte mein Skript das zuerst prüfen und, falls bereits gescannt wird, später erneut versuchen.
  • Wenn der MCEBuddy-Service während eines Scans eine temporäre Datei oder einen Registrierungswert anlegte, könnte mein Skript das prüfen und bei Vorhandensein später erneut versuchen.
  • Wenn der MCEBuddy-Service sogar nur einen Debug-Log-Eintrag schreiben würde, wann ein Scan beginnt und endet, könnte mein Skript das Log durchsuchen und so den Status verfolgen. Das wäre furchtbar ineffizient, aber immer noch um Größenordnungen besser, als ständig alle Videodateien zu scannen.

Sofern ich nichts übersehen habe, werde ich wohl ein Feature-Request für eine dieser Verhaltensänderungen in MCEBuddy stellen müssen. Aber ich dachte, ich frage zuerst die Community, ob jemand eine Idee hat.

Ich liebe MCEBuddy und will es einfach nur gut nutzen. Danke, dass ihr euch die Ausführungen eines Verrückten anhört!

Das ist eine sehr saubere Konfiguration, und wir lieben die Art und Weise, wie Sie MCEBuddy nutzen.

Ihr Vorschlag ist eine gute Idee, und wir haben ihn in die neueste 2.5.8 BETA-Version aufgenommen. Probieren Sie es aus.

Nun wird ein true oder false zurückgegeben. Es wird false zurückgegeben, wenn eine dieser Bedingungen erfüllt ist:

  1. Die Engine läuft nicht
  2. Ein Monitor-Standort-Scan läuft bereits
  3. Eine Konvertierte-zu-Quelle-Datei-Synchronisierung läuft (dieses Feature wird aktiviert, wenn Sie die Option „Konvertierte Datei mit Quelle synchronisieren“ aktiviert haben)

Gans,

Wow! Ich hätte nicht erwartet, so schnell eine Antwort zu bekommen, noch dass du eine so nischenspezifische Anpassung mit so wenig Widerstand umsetzt, basierend auf einem informellen Bericht über etwas, das eindeutig kein Fehler, sondern ein Nicht-Feature war. Es ist offensichtlich, dass dies ein Lieblingsprojekt für dich ist – so sollten alle kleinen, gemeinschaftsgetriebenen Projekte sein.

Außerdem funktioniert es großartig und erfüllt meine Bedürfnisse perfekt! Vielen Dank! Ich werde vermutlich nie wieder den „Erneut scannen“-Button klicken müssen! :smiling_face_with_three_hearts:

~ Toast