This was observed on Windows 7 machines at the January training session on single frame simulations.
On a single capture simulation, the progress bar stopped at 83% even though all 6 of 6 scheduled events were performed. We think this is because of the order that the progress bar current and maximum values were updated.
A fix has been added and will be tested on the training laptops.
We noticed that this issue has persisted and the proposed fix from a year and a half ago didn't work.
The bug seemed to be isolate to Windows laptops, but we believe that it has been observed on Linux and Mac as well (just far less rarely).
After some thorough testing and debugging on Windows, it was discovered that if the routine that scans the output of the dirsig sub-process was long and contained more than one event update message, that the progress bar update logic would not work correctly. Perhaps the reason the problem occurred so regularly on Windows was because the process output was processed less frequently, which resulted in larger output text chunks and an increased liklihood of multiple event messages.
Improved logic was introduced for the 4.6.3 release.