As with PR #3, I want to make sure that we don't block OctoPrint's main thread when we're parsing all of the files to see which contain M300 commands. The file access was blocking, so on older hardware with lots of .gcode files uploaded the UI could stall before successfully loading for a few minutes (appears "stuck" even though it's just blocked temporarily). These changes:
Decouple file parsing logic from the main plugin class.
Added a queue for parsing through files one-by-one. When the queue is populated a new thread is spun up so that these are now parsed asynchronously.
Added a warning message to the Events settings panel if any files are queued for processing... since we no longer block, the files won't be populated in this panel on first launch so the message lets users know they can try restarting the server after a bit.
Added a debug config (not exposed) for additional logging and an easy way to clear M300 Analysis metadata for quicker testing.
Screenshot of Debug Panel
Test Plan
[x] verified a warning message appears in the Events panel on the first launch (when no metadata was stored)
[x] verified custom gcode files appear in the Events drop-downs after parsing and restarting the server
[x] verified functionality of the file parsing still works as expected, otherwise
[x] verified an older Raspberry Pi 2B now loads the UI quickly with this change in place
[x] added a debug panel and button for clearing out metadata to "reset" the file parsing state for quicker testing
Description
As with PR #3, I want to make sure that we don't block OctoPrint's main thread when we're parsing all of the files to see which contain M300 commands. The file access was blocking, so on older hardware with lots of .gcode files uploaded the UI could stall before successfully loading for a few minutes (appears "stuck" even though it's just blocked temporarily). These changes:
Screenshot of Debug Panel
Test Plan