1. Run pulseview (with the log-level patch):
$ pulseview -l4
2. Connect to the OLS
3. Run a single session to the end. The samples should appear correctly.
4. Run a second session. No samples are displayed, and the uncompleted sampling session locks up, without sending SR_DF_END. The sampling thread is stuck in sr_sampling_run.
5. Click close. SR_DF_END is sent, but the sampling thread is still stuck in sr_sampling_run. PulseView joins to this thread, which prevents it from closing.
(09:29:19) jhol: what's the general problem?
(09:30:01) biot: we initialize devc, every driver's (unique) device-specific context, when the device is discovered at scan time.
(09:30:18) biot: devc contains things like the usb/serial transport, so that's correct
(09:31:14) biot: b ut it also contains things like the # of samples received, and various other things like that which are _acquisition_ specific, and as such should be reset before every acquisition
(09:31:47) biot: in the case of the OLS, that's the culprit -- the sample counter never gets reset
(09:31:52) biot: hilarity ensues
(09:32:45) biot: to make matters worse, we never really distinguish between a reset after scan and a reset before acq, as it's never been necessary for the cli
(09:33:14) biot: we usually g_try_malloc0() the devc, thus making it all 0
(09:33:48) biot: so it'll require a bit of thought for every driver, not just a big copy-paste operation
Fixed in bf25678359