我在這裡使用的是 MCEBuddy 2.5.7 Premium。我把 MCEBuddy 設定成去掃描位於另一台 Windows 檔案伺服器上的 SMB1 共用資料夾，尋找要轉檔的檔案。（沒錯，我知道 SMB1 不安全，但現在還沒辦法改。）透過 SMB1 掃描龐大的目錄樹並不快，我的掃描常常要花上大約 10 分鐘。預設輪詢週期是 5 分鐘，導致掃描流量幾乎沒停，製造了大量不必要的網路與磁碟/CPU 負載。我沒有直接把掃描間隔調高，而是寫了幾支腳本來讓流程更有效率。
現在我在 Windows 檔案伺服器上跑了一支腳本，用 Win32 目錄服務 API 監控那些目錄。因為它是事件驅動而非輪詢驅動，我的腳本不必主動去檢查檔案是否變動；作業系統會在有異動時立刻通知腳本。只要樹狀結構裡有任何變化，腳本就在共用資料夾裡放一個標記檔。（它還加了遲滯機制，把連續多次異動視為一次，並在異動停止後等待一段合理時間。）另一支在 MCEBuddy 主機上的腳本每 60 秒檢查這個標記檔是否存在。若存在，就刪除標記檔，並透過執行「MCEBuddy.UserCLI.exe --command=engine --action=rescan」觸發 MCEBuddy 重新掃描。MCEBuddy 本身的輪詢週期則設成 1 週（604800 秒），以防腳本漏掉任何異動。這解決了我原本的效能問題：MCEBuddy 主機現在只對單一檔案做「是否存在」檢查，而非透過 SMB1 不間斷地掃描數千個檔案；只有在必要時才會執行完整掃描。
但 MCEBuddy 處理「MCEBuddy.UserCLI.exe --command=engine --action=rescan」的方式，在我已經在掃描時會造成一個小問題。
我期望 MCEBuddy 的行為：
- 中止並從頭重新掃描。
－或－ - 將（最多 1 個）重新掃描請求排隊，等目前掃描結束後再掃一次。
實際上 MCEBuddy 的行為：
接受但忽略重新掃描請求，並回報成功：
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.UserSuccessful!!
這導致若 MCEBuddy 正在掃描時發生異動，那些變更會被漏掉。
關鍵在於，只要我能用程式方式知道 MCEBuddy 是否正在掃描，就能輕鬆繞過這問題…但我沒辦法。只要下列任一點小改變，我就能處理：
- 若 MCEBuddy 採用上述任一種建議行為（首選方案），我就什麼都不用再做。
- 若 MCEBuddy.UserCLI.exe 回傳失敗而非成功，我的腳本就能稍後重試。
- 若 MCEBuddy.UserCLI.exe 能查詢引擎是否正在掃描，我的腳本就能先查詢，若已在掃描就稍後重試。
- 若 MCEBuddy 服務會放一個暫存檔或登錄值表示正在掃描，我的腳本就能先檢查，若存在就稍後重試。
- 若 MCEBuddy 服務會在開始與結束掃描時寫入 debug 層級的日誌項目，我的腳本就能持續讀取日誌並根據那些項目追蹤狀態。這雖然極沒效率，但仍比不斷掃描所有影片檔案好上許多。
除非我遺漏了什麼，否則我大概得針對上述任一項行為提出功能請求。但還是先來這裡問問大家有沒有其他點子。
我愛 MCEBuddy，只想把它用得更好。感謝各位聽我這瘋子碎碎念！
