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