Rescan via CLI wordt genegeerd als er al een scan bezig is

Fouten / Functieverzoeken Nieuwe functies
1

Ik gebruik hier MCEBuddy 2.5.7 Premium. Ik heb MCEBuddy ingesteld om een SMB1-bestandsshare op een aparte Windows-fileserver te scannen naar te converteren bestanden. (Ja, ik weet dat SMB1 onveilig is, maar ik kan dat op dit moment niet veranderen.) Het scannen van een grote directorystructuur over SMB1 is niet snel, en mijn scans duurden vaak ongeveer 10 minuten. Met de standaard poll-periode van 5 minuten was de scanverkeer constant en veroorzaakte veel onnodige netwerkverkeer en schijf/CPU-belasting. In plaats van de scaninterval simpelweg te verhogen, heb ik een paar scripts geschreven om dit efficiënter te maken.

Nu heb ik een script draaien op de Windows-fileserver dat de betreffende directories controleert via de Win32 directory services API. Omdat het event-gedreven is in plaats van polling-gedreven, hoeft mijn script niet te pollĂ©n om te zien of bestanden zijn veranderd; het besturingssysteem informeert mijn script onmiddellijk wanneer dat gebeurt. Als er iets in de boomstructuur verandert, plaatst mijn script een markeringbestand in de share. (Het gebruikt ook wat hysterese om meerdere opeenvolgende wijzigingen als Ă©Ă©n wijziging te beschouwen en een redelijke tijd te wachten tot wijzigingen stoppen.) Een tweede script op de MCEBuddy-machine pollt elke 60 seconden naar het bestaan van dat ene markeringbestand. Als het markeringbestand aanwezig is, verwijdert het dat bestand en start het een herscan in MCEBuddy door “MCEBuddy.UserCLI.exe --command=engine --action=rescan” uit te voeren. De poll-periode van MCEBuddy zelf staat op 1 week (604800 seconden) om alles op te vangen dat het script om wat voor reden dan ook gemist zou kunnen hebben. Dit lost mijn oorspronkelijke prestatieprobleem op, want in plaats van duizenden bestanden nonstop over SMB1 te scannen, doet de MCEBuddy-machine alleen een “if exist” op Ă©Ă©n bestand, waarna MCEBuddy pas een volledige scan uitvoert wanneer dat nodig is.

Maar er is een klein probleem veroorzaakt door de manier waarop MCEBuddy omgaat met “MCEBuddy.UserCLI.exe --command=engine --action=rescan” als er al een scan bezig is.

Wat ik verwacht dat MCEBuddy doet:

  1. De huidige scan afbreken en opnieuw beginnen.
  • OF -
  1. (Maximaal 1) verzoek tot herscan in de wachtrij plaatsen totdat de huidige scan klaar is, daarna opnieuw scannen.

Wat MCEBuddy werkelijk doet:
Het verzoek tot herscan accepteren maar negeren, en succes teruggeven:
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!!

Hierdoor worden wijzigingen gemist als er een wijziging plaatsvindt terwijl MCEBuddy al aan het scannen is.

De clou is dat ik dit gemakkelijk zou kunnen omzeilen als ik op welke manier dan ook programmatisch kon achterhalen of MCEBuddy momenteel een scan uitvoert
 maar dat kan ik niet. Als er ook maar Ă©Ă©n van een paar kleine dingen veranderde, zou ik ermee kunnen leven:

  • Als MCEBuddy een van de hierboven voorgestelde gedragingen vertoonde (de voorkeursoplossing), hoefde ik niets meer te doen.
  • Als MCEBuddy.UserCLI.exe falend in plaats van succesvol zou teruggeven, kon mijn script de herscan later opnieuw proberen.
  • Als MCEBuddy.UserCLI.exe een manier had om de engine te bevragen of hij momenteel aan het scannen is, kon mijn script dat eerst controleren en, als er al gescand wordt, later opnieuw proberen.
  • Als de MCEBuddy-service een tijdelijk bestand of registerwaarde aanmaakte die aangeeft dat een scan bezig is, kon mijn script die eerst controleren en, als het bestand/de registerwaarde bestaat, later opnieuw proberen.
  • Als de MCEBuddy-service zelfs maar een debug-level logregel zou schrijven wanneer een scan start en wanneer die eindigt, kon mijn script voortdurend dat log scrapen en naar die regels zoeken om een beeld van MCEBuddy’s status te behouden. Dat zeefficiĂ«nt zijn, maar nog steeds ordes van grootte efficiĂ«nter dan constant alle videobestanden scannen.

Tenzij ik iets over het hoofd zie, verwacht ik dat ik een feature-verzoek zal moeten indienen om een van deze gedragingen in MCEBuddy te wijzigen. Maar ik dacht eerst de menigte te vragen of ze nog andere ideeën hebben.

Ik ben dol op MCEBuddy en wil het gewoon goed gebruiken. Bedankt voor het aanhoren van de verhalen van een gek!

2

Dit is een erg nette setup en we houden van de manier waarop je MCEBuddy gebruikt.

Wat je hebt voorgesteld is een goed idee en we hebben het verwerkt in de nieuwste 2.5.8 BETA-versie. Probeer het uit.

Nu retourneert het een true of false. Het retourneert een false als een van deze voorwaarden wordt voldaan:

  1. De engine draait niet
  2. Er is al een monitorlocatie-scan bezig
  3. Er is een conversie naar bronbestand-synchronisatie bezig (deze functie wordt geactiveerd als je de optie ‘Sync converted file to source’ hebt ingeschakeld)
3

Gans,

Wauw! Ik had niet verwacht zo snel een reactie te krijgen, en al helemaal niet dat je zo’n niche-aanpassing zou doorvoeren met zo weinig weerstand, op basis van een informele melding van iets dat duidelijk geen bug was maar een niet-bestaande functie. Het is duidelijk dat dit een arbeid van liefde voor je is, zoals alle kleine, door de community gedreven projecten zouden moeten zijn.

Bovendien werkt het geweldig en beantwoordt het perfect aan mijn behoeften! Heel erg bedankt! Ik zal waarschijnlijk nooit meer op die “Opnieuw scannen”-knop hoeven te klikken! :smiling_face_with_three_hearts:

~ Toast