I’m using MCEBuddy 2.5.7 Premium here. I have MCEBuddy set up to scan an SMB1 file share on a separate Windows file server for files to convert. (Yes, I know SMB1 is insecure but I can’t change that right now.) Scanning a large directory tree over SMB1 isn’t fast, and my scans would often take around 10 minutes. With the default poll period of 5 minutes, the scan traffic was constant and creating a lot of unneeded network traffic and disk/CPU activity. Instead of just bumping the scan interval higher, I whipped up a couple of scripts to make this more efficient.
Now I have a script running on the Windows file server that monitors the directories in question using the Win32 directory services API. Since it is event-driven rather than polling-driven, my script never has to poll to see if files have changed; instead, the OS informs my script immediately whenever that happens. If anything in the tree changes, my script plants a marker file in the share. (It also employs some hysteresis to treat multiple consecutive changes as a single change and wait a reasonable amount of time until changes stop occurring.) A second script running on the MCEBuddy machine polls every 60 seconds for the existence of that one marker file. If the marker file exists, it deletes the marker file and initiates a rescan in MCEBuddy by executing “MCEBuddy.UserCLI.exe --command=engine --action=rescan”. MCEBuddy’s actual poll period is set to 1 week (604800 seconds) to catch anything that the script may have missed for whatever reason. This solves my original performance problem, because instead of scanning thousands of files nonstop over SMB1, the MCEBuddy machine is only doing an “if exist” on a single file, then MCEBuddy is doing a full scan only when it needs to.
But there is a little problem caused by the way that MCEBuddy deals with “MCEBuddy.UserCLI.exe --command=engine --action=rescan” if a scan is already in progress.
What I expect MCEBuddy to do:
- Abort and restart the current scan from the beginning.
- OR -
- Queue (up to 1) request for rescan until after the current scan is finished, then scan again.
What MCEBuddy actually does:
Accepts but ignores the request for rescan, and returns success:
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!!
This is causing changes to be missed, if a change occurs while MCEBuddy is already scanning.
The kicker here is that I could easily work around this if I had any programmatic insight as to whether MCEBuddy is currently running a scan… but I don’t. If any one of several little things changed, I could actually deal with this:
- If MCEBuddy exhibited one of the suggested behaviors above (preferred solution), I wouldn’t have to do anything more.
- If MCEBuddy.UserCLI.exe returned failure instead of success, my script could try the rescan again later.
- If MCEBuddy.UserCLI.exe had a way to query the engine to see if it is currently scanning, my script could do this first, and if it is already scanning, try again later.
- If the MCEBuddy Service planted a temporary file or registry value showing that a scan is currently in progress, my script could check this first, and if the file/registry value exists, try again later.
- If the MCEBuddy Service even wrote a debug-level log entry stating when it begins a scan and ends a scan, my script could continually scrape the log and look for those entries to maintain an account of MCEBuddy’s status. This would be terribly inefficient, but still orders of magnitude more efficient than scanning all video files constantly.
Unless I’ve missed something, I expect I’ll have to place a feature request for one of these behaviors to be changed in MCEBuddy. But I thought I would ask the crowd first for any other ideas.
I love MCEBuddy and just want to use it well. Thanks for entertaining the yarns of a crazy person!
