Currently PV re-queries trigger settings from libsigrok many times during an acquisition, which is not necessary and can be a performance and log readability issue since libsigrok generates log message for the query. PV should probably only query triggers once upon acquisition start and cache the value.
Fixed in 2795de2e7fdaeb6e9f672e0dc73dea328f35e585, thanks!
Restested with the latest build. After trying multiple captures in a row, the problem of the freezing gui reoccurs, so it isnt entirely fixed, but the gui behaves way better and is more workable. You can confirm this simply by pressing the Run vutton multiple times in short succession. So whatever you did improved on the problem, and postponed the crash. I might suggest checking/resetting the initial state prior to each capture, to my noob eyes it might just be a matter of correctly cleaning up or initialising prior to communicating with libsigrok (based on what you said).
I noticed something very weird, but maybe related to this problem: Every 2nd capture the text 'ms' in the timeline changes to 'msa'. When the 'ms' text is displayed the capture is done correctly. When the 'msa' text is displayed the capture is empty. I would not expect this based on what i see on the gui. Can it be that cause of some condition a different piece of code is run where it shouldnt?
Shadowfax, your reports are unfortunately confusing to me since I don't see how they relate to this bug report. Would you mind elaborating and/or creating a new bug report for the issue you're facing? > After trying multiple captures in a row, the problem of the freezing gui reoccurs This bug doesn't mention a freezing GUI, so which issue are you refering to? > I might suggest checking/resetting the initial state prior to each capture Initial state of... what? The trigger state? > very 2nd capture the text 'ms' in the timeline changes to 'msa'. When the 'ms' text is displayed the capture is done correctly. When the 'msa' text is displayed the capture is empty. This is expected on my part. The "sa" time unit stands for "samples" and is used when there is no sample rate information provided by the driver. No sample rate information and no sample data mean that the driver didn't even begin the acquisition.
Ah ok, it was confusing to me ;) Anyway, the gui still freezes up, but it takes a couple of more captures to do so. All my tests are done with the latest firmware, which is 3.07 DemonCore ( https://github.com/GadgetFactory/OpenBench-Logic-Sniffer/tree/master/OLS_Upgrader/FPGAROM ). As it goes with OpenSource stuff, it is trial and error and finding info trying to figure out whats happening and why. (sidenote: The reason for the msa i found searching on the internet: http://dangerousprototypes.com/forum/viewtopic.php?t=5411&p=51881 The ols firmware seems to cause this at some extend. A reset to prevent this prior to capture, however the Java based OLS software is unaffected and does not require a reset as mentioned in threads. Im wondering why it behaves different for PulseView and OLS).
Sorry ShadowFax, I think what you're explaining is completely irrelevant for this bug. If you're encountering a bug with the OLS, please open a bug report for that device driver.