LimaGroup issueshttps://gitlab.esrf.fr/groups/limagroup/-/issues2023-09-15T19:28:27+02:00https://gitlab.esrf.fr/limagroup/lima/-/issues/198writeFrame (manual saving) deadlock2023-09-15T19:28:27+02:00Samuel DebionnewriteFrame (manual saving) deadlockKindly reported by @denolf
This issue affects scan with autof for instance.
Repro:
```
ssh bcu-ci-lab1
mkdir output
cd output
git clone https://gitlab.esrf.fr/bliss/bliss.git
docker run -it -v $HOME/output esrfbcu/bliss-ci-runner:m...Kindly reported by @denolf
This issue affects scan with autof for instance.
Repro:
```
ssh bcu-ci-lab1
mkdir output
cd output
git clone https://gitlab.esrf.fr/bliss/bliss.git
docker run -it -v $HOME/output esrfbcu/bliss-ci-runner:master /bin/bash
rm /dev/random && ln -s /dev/urandom /dev/random || true
. /opt/conda/etc/profile.d/conda.sh
. /opt/conda/etc/profile.d/mamba.sh
mamba activate default_env
cd /output/bliss
export PYTHON_VERSION=3.9
mamba install --file conda-requirements.txt --file conda-requirements-dev.txt python=$PYTHON_VERSION -c esrf-bcu
pip install .[dev] ./blissdata
export LIMA_SIMULATOR_CONDA_ENV=lima_env
mamba env create --name $LIMA_SIMULATOR_CONDA_ENV -f bliss_lima_simulators/conda-environment.yml
while pytest tests/nexus_writer/test_nxw_autofilter.py::test_nxw_autofilter;do echo 'ok';done
```
leads to the following trace:
```
[2023/07/27 12:33:28.305962] 7fe47ef36700 *Application*Lima.Server.LimaCCDs::LimaCCDs::writeImage (LimaCCDs.py:2063)-Funct: Enter
[2023/07/27 12:33:28.306009] 7fe47ef36700 *Control*Control::Saving::writeFrame (control/src/CtSaving.cpp:1775)-Funct: Enter
[2023/07/27 12:33:28.306030] 7fe47ef36700 *Control*Control::Saving::writeFrame (control/src/CtSaving.cpp:1776)-Param: aFrameNumber=47
[2023/07/27 12:33:28.306054] 7fe47ef36700 *Control*Control::Saving::_waitWritingThreads (control/src/CtSaving.cpp:1081)-Funct: Enter
[2023/07/27 12:33:28.306076] 7fe47ef36700 *Control*Control::Control::ImageStatus::ImageStatus (control/src/CtControl.cpp:1358)-Funct: Enter
[2023/07/27 12:33:28.306101] 7fe47ef36700 *Control*Control::Control::ImageStatus::ImageStatus (control/src/CtControl.cpp:1358)-Funct: Exit
[2023/07/27 12:33:28.306127] 7fe47ef36700 *Control*Control::Control::Status::Status (control/src/CtControl.cpp:1393)-Funct: Enter
[2023/07/27 12:33:28.306150] 7fe47ef36700 *Control*Control::Control::Status::Status (control/src/CtControl.cpp:1393)-Funct: Exit
[2023/07/27 12:33:28.306172] 7fe3f1bc6700 *Control*Control::Control::ReadImage (control/src/CtControl.cpp:827)-Funct: Enter
[2023/07/27 12:33:28.306264] 7fe3f1bc6700 *Control*Control::Control::ReadImage (control/src/CtControl.cpp:828)-Param: frameNumber=-1, readBlockLen=1
[2023/07/27 12:33:28.306299] 7fe3f1bc6700 *Control*Control::Control::readBlock (control/src/CtControl.cpp:843)-Funct: Enter
[2023/07/27 12:33:28.306326] 7fe3f1bc6700 *Control*Control::Control::readBlock (control/src/CtControl.cpp:844)-Param: frameNumber=-1, readBlockLen=1, baseImage=0
[2023/07/27 12:33:28.306355] 7fe3f1bc6700 *Control*Control::Image::getImageDim (control/src/CtImage.cpp:652)-Funct: Enter
[2023/07/27 12:33:28.306382] 7fe3f1bc6700 *Control*Control::Acquisition::getAcqMode (control/src/CtAcquisition.cpp:444)-Funct: Enter
[2023/07/27 12:33:28.306406] 7fe3f1bc6700 *Control*Control::Acquisition::getAcqMode (control/src/CtAcquisition.cpp:448)-Return: mode=Single
[2023/07/27 12:33:28.306432] 7fe3f1bc6700 *Control*Control::Acquisition::getAcqMode (control/src/CtAcquisition.cpp:444)-Funct: Exit
[2023/07/27 12:33:28.306456] 7fe3f1bc6700 *Control*Control::Image::getImageType (control/src/CtImage.cpp:629)-Funct: Enter
[2023/07/27 12:33:28.306480] 7fe3f1bc6700 *Control*Control::Acquisition::getAcqMode (control/src/CtAcquisition.cpp:444)-Funct: Enter
[2023/07/27 12:33:28.306504] 7fe3f1bc6700 *Control*Control::Acquisition::getAcqMode (control/src/CtAcquisition.cpp:448)-Return: mode=Single
[2023/07/27 12:33:28.306528] 7fe3f1bc6700 *Control*Control::Acquisition::getAcqMode (control/src/CtAcquisition.cpp:444)-Funct: Exit
[2023/07/27 12:33:28.306552] 7fe3f1bc6700 *Control*Control::Image::getImageType (control/src/CtImage.cpp:641)-Return: type=Bpp32
[2023/07/27 12:33:28.306578] 7fe3f1bc6700 *Control*Control::Image::getImageType (control/src/CtImage.cpp:629)-Funct: Exit
[2023/07/27 12:33:28.306621] 7fe3f1bc6700 *Control*Control::Sofware BinRoiFlip::getSize (control/src/CtImage.cpp:141)-Funct: Enter
[2023/07/27 12:33:28.306670] 7fe3f1bc6700 *Control*Control::Sofware BinRoiFlip::getSize (control/src/CtImage.cpp:143)-Trace: m_max_size=<1024x1024>, m_bin=<1x1>, m_roi=<0,0>-<0x0>
[2023/07/27 12:33:28.306708] 7fe3f1bc6700 *Control*Control::Sofware BinRoiFlip::getSize (control/src/CtImage.cpp:150)-Return: m_size=<1024x1024>
[2023/07/27 12:33:28.306742] 7fe3f1bc6700 *Control*Control::Sofware BinRoiFlip::getSize (control/src/CtImage.cpp:141)-Funct: Exit
[2023/07/27 12:33:28.306774] 7fe3f1bc6700 *Control*Control::Image::getImageDim (control/src/CtImage.cpp:660)-Return: dim=<1024x1024x4-Bpp32>
[2023/07/27 12:33:28.306806] 7fe3f1bc6700 *Control*Control::Image::getImageDim (control/src/CtImage.cpp:652)-Funct: Exit
[2023/07/27 12:33:28.306839] 7fe3f1bc6700 *Control*Control::Saving::getManagedMode (control/src/CtSaving.cpp:1226)-Funct: Enter
[2023/07/27 12:33:28.306894] 7fe47ef36700 *Control*Control::Control::getStatus (control/src/CtControl.cpp:695)-Funct: Enter
```
where threads `7fe3f1bc6700` and `7fe47ef36700` deadlocks:
- thread1 `CtSaving::writeFrame` takes `CtSaving` mutex
- thread2 `CtControl::ReadImage` takes `CtControl` mutex
- thread1 in `writeFrame` calls `Control::getStatus` that try to take `CtControl` mutex
- thread2 in `ReadImage` calls `Saving::getManagedMode` that try to take `CtSaving` mutex
The mutexes are used with conditional variables and thus are NOT recursive.v1.9.23Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/164Implement HDF5 metadata from Detector Info2023-01-12T14:53:31+01:00Samuel DebionneImplement HDF5 metadata from Detector InfoHDF5 metadata are currently filled with dummy values.HDF5 metadata are currently filled with dummy values.ID29 restarthttps://gitlab.esrf.fr/limagroup/lima2/-/issues/159Make the Receiver Allocator Aware2023-01-12T14:53:58+01:00Samuel DebionneMake the Receiver Allocator AwareStarting with the `simulator`:
```
class receiver
{
receiver(std::pmr::polymorphic_allocator allocator = std::allocator());
...
```
then the allocator should be used to allocate the `data_t` provided to `on_frame_ready()` callback.Starting with the `simulator`:
```
class receiver
{
receiver(std::pmr::polymorphic_allocator allocator = std::allocator());
...
```
then the allocator should be used to allocate the `data_t` provided to `on_frame_ready()` callback.ID29 restarthttps://gitlab.esrf.fr/limagroup/lima2/-/issues/156Compression on writer_sparse datasets not supported2022-12-05T15:20:54+01:00Samuel DebionneCompression on writer_sparse datasets not supportedThe compression setting is exposed to the user but not properly supported, aka only compression=`none` works.
In the `writer_sparse`, the `dcpl` is defined and used for the radius-1d and `radius_mask` datasets but those are written with...The compression setting is exposed to the user but not properly supported, aka only compression=`none` works.
In the `writer_sparse`, the `dcpl` is defined and used for the radius-1d and `radius_mask` datasets but those are written without chunking, resulting in:
```
H5Dint.c line 1319 in H5D__create(): filters can only be used with chunked layout
```https://gitlab.esrf.fr/limagroup/lima2/-/issues/155Add HDF5 dataformat attribute on NxData group2022-12-06T08:38:17+01:00Samuel DebionneAdd HDF5 dataformat attribute on NxData groupSee https://github.com/silx-kit/fabio/issues/500See https://github.com/silx-kit/fabio/issues/500Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/149Add support for init_params per device2023-07-21T14:33:49+02:00Samuel DebionneAdd support for init_params per device`plugins_params` is currently a device property of the control device that is broadcasted to each/every devices that belong to the app.
Multiple options:
- One config file with all the init params as `plugins_params` (a la PSI)
- a vec...`plugins_params` is currently a device property of the control device that is broadcasted to each/every devices that belong to the app.
Multiple options:
- One config file with all the init params as `plugins_params` (a la PSI)
- a vector plugin params with configuration for each devices (a la Smartpix)
- each device has it's own `plugin_params`, aka not broadcasted anymore (a la Sam :-))
@ponsard has a PR ready to implement option 2. @alejandro.homs what do you think?https://gitlab.esrf.fr/limagroup/lima2/-/issues/147Support continuous / infinite acquisition2023-07-21T14:34:13+02:00Samuel DebionneSupport continuous / infinite acquisitionBliss `timescan`s fails because `io_hdf5_node` does not support a number of frames unknown at creation time.Bliss `timescan`s fails because `io_hdf5_node` does not support a number of frames unknown at creation time.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/125Implement Trigger Modes2022-07-18T17:10:35+02:00Samuel DebionneImplement Trigger Modes- [ ] Software
- [ ] External
- [ ] Gate (exposition given by the pulse)
With an additional parameter `nb_frames_per_trigger`.
- `Software && nb_frames_per_trigger == nb_frames` is equivalent to "Internal trigger"
- `Software && nb_fra...- [ ] Software
- [ ] External
- [ ] Gate (exposition given by the pulse)
With an additional parameter `nb_frames_per_trigger`.
- `Software && nb_frames_per_trigger == nb_frames` is equivalent to "Internal trigger"
- `Software && nb_frames_per_trigger == 1` is equivalent to "Internal trigger multi"
- `External && nb_frames_per_trigger == nb_frames` is equivalent to "External trigger"
- `External && nb_frames_per_trigger == 1` is equivalent to "External trigger multi"
More combinations are possible with this configuration.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/170lz4 lib 1.8.2 deps is not compatible with latest pytango and boost-cpp versions2022-03-09T15:29:43+01:00Laurent Claustrelz4 lib 1.8.2 deps is not compatible with latest pytango and boost-cpp versionsSince boost-cpp 1.74.0 lz4-c >= 1.9.3 (deps for zstd) is mandatory. lima conda package build pins on lz4-c strict version 1.8.2.
Since lz4-c 1.8.2 the new version 1.9.3 is improving a lot the compress/decompression speed performance and ...Since boost-cpp 1.74.0 lz4-c >= 1.9.3 (deps for zstd) is mandatory. lima conda package build pins on lz4-c strict version 1.8.2.
Since lz4-c 1.8.2 the new version 1.9.3 is improving a lot the compress/decompression speed performance and provides a long list of bug fixes, have a look here https://github.com/lz4/lz4/releases
By pinning lz4-c to strict version 1.8.2 pytango and cpptango cannot be upgraded and only the package version 9.3.2 can solve conda package conflicts. pytango 9.3.2 is only available from the channel tango-controls, but it seems now the official channel must be conda-forge where only version 9.3.3 and upper will be available.Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/113Build with LTO only in Release builds2022-04-08T11:54:25+02:00Samuel DebionneBuild with LTO only in Release buildsLTO/IPO should only be enable on release builds as it tricks the debugger and slows down the compile time.
``` diff
- INTERPROCEDURAL_OPTIMIZATION ON
+ INTERPROCEDURAL_OPTIMIZATION_RELEASE ON
```LTO/IPO should only be enable on release builds as it tricks the debugger and slows down the compile time.
``` diff
- INTERPROCEDURAL_OPTIMIZATION ON
+ INTERPROCEDURAL_OPTIMIZATION_RELEASE ON
```Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/112Logging not properly initialized2022-03-03T16:57:03+01:00Samuel DebionneLogging not properly initializedThe logger initialization is missing in the Tango DS main, consequently the log filters are not properly applied.
Furthmore, it's not clear how this setting is supposed to be set:
- with the CLI, using `--log-level` option
- with the in...The logger initialization is missing in the Tango DS main, consequently the log filters are not properly applied.
Furthmore, it's not clear how this setting is supposed to be set:
- with the CLI, using `--log-level` option
- with the init_params Tango properties
- both, but then which one takes precedence?Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/122Follow-up from "Fix HDF5 parallel saving": formalize SaveContainer::Handler2020-09-03T16:51:41+02:00Alejandro Homs PuronFollow-up from "Fix HDF5 parallel saving": formalize SaveContainer::HandlerThe following discussion from !167 should be addressed:
- [ ] @alejandro.homs started a [discussion](https://gitlab.esrf.fr/limagroup/lima/-/merge_requests/167#note_77915):
> The problem is fixed for `HDF5`, but other `SaveContain...The following discussion from !167 should be addressed:
- [ ] @alejandro.homs started a [discussion](https://gitlab.esrf.fr/limagroup/lima/-/merge_requests/167#note_77915):
> The problem is fixed for `HDF5`, but other `SaveContainer`s are not state-less, like `EDF`.
>
> By formalizing `SaveContainer::Handler` we avoid this kind of issuesv1.10.0Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima/-/issues/121Saving on multiple files fails when compression is active at high frame rate...2020-09-03T16:53:11+02:00Alejandro Homs PuronSaving on multiple files fails when compression is active at high frame rate (22 kHz) and low photon countsWhen the following conditions met:
* saving with compression on more than one file per acquisition
* maximum `PSI/Eiger-500k` speed on 4-bits sensor `pixel_depth`
* low pixel count
the acquisition fails due to a wrong `offset` when cal...When the following conditions met:
* saving with compression on more than one file per acquisition
* maximum `PSI/Eiger-500k` speed on 4-bits sensor `pixel_depth`
* low pixel count
the acquisition fails due to a wrong `offset` when calling `H5DOwrite_chunk()`:
```
[2020/06/24 12:27:10.643687] 7f8207fff700 *Control*Control::Saving HDF5 Container::_writeFile (/users/blissadm/Git/Lima/control/src/CtSaving_Hdf5.cpp:730)-Error: Exception(Error): H5DOwrite_chunk() failedaData.frameNumber=9002, m_file_cnt=10, offset[0]=1001, buf_size=3059 [thrown]
[2020/06/24 12:27:10.643913] 7f8207fff700 *Control*Control::Saving HDF5 Container::_writeFile (/users/blissadm/Git/Lima/control/src/CtSaving_Hdf5.cpp:749)-Error: Exception(Error): Control: _writeFile(/users/blissadm/Git/Lima/control/src/CtSaving_Hdf5.cpp, 730): Error: H5DOwrite_chunk() failedaData.frameNumber=9002, m_file_cnt=10, offset[0]=1001, buf_size=3059 [thrown]
[2020/06/24 12:27:10.643997] 7f8207fff700 *Control*Control::Saving::_setSavingError (/users/blissadm/Git/Lima/control/src/CtSaving.cpp:1947)-Error: m_ctrl.m_status=<AcquisitionStatus=AcqFault, Error=Saving error, ImageCounters=<LastImageAcquired=10603, LastBaseImageReady=10603, LastImageReady=10603, LastImageSaved=9001, LastCounterReady=-1>, saving_mode=1
```
The current Lima core allows parallelization of saving for the first frame of a file. When photon count is low, compression is very fast and competes with saving. Under these conditions, a new file can be opened while the previous is still in use. However, `CtSaving::SaveContainer` implementations are not state-less, and fail when more than one file is open at the same time.
Indeed, the problem is solved with the following patch:
```diff
index fd9d695..fff435c 100755
--- a/control/src/CtSaving.cpp
+++ b/control/src/CtSaving.cpp
@@ -2468,7 +2468,6 @@ void CtSaving::SaveContainer::prepare(CtControl& ct)
bool new_file = !(i % pars.framesPerFile);
if (new_file) ++nextNumber;
frame_par.m_pars.nextNumber = nextNumber;
- frame_par.m_threadable = new_file;
}
std::pair<Frame2Params::iterator, bool> result =
m_frame_params.insert(Frame2Params::value_type(i, frame_par));
```v1.9.6Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima/-/issues/118h5 saving: frames_per_file not adjusted to the nb of frames2020-06-29T10:45:21+02:00Laurent Claustreh5 saving: frames_per_file not adjusted to the nb of framesWhen acquiring less frames than the frames_per_file parameter, CtSaving must passed to h5 container a total number of frames = to the acq number of frames if it it less than the parameters frames_per_files. And if more than one file is r...When acquiring less frames than the frames_per_file parameter, CtSaving must passed to h5 container a total number of frames = to the acq number of frames if it it less than the parameters frames_per_files. And if more than one file is required to save all the frames (frames_per_file < acq_nb_frames) the last file must be created for the exact number of remaining frames.
v1.9.5https://gitlab.esrf.fr/limagroup/lima/-/issues/117manual saving broken with frame number equal -12020-06-29T10:45:21+02:00Laurent Claustremanual saving broken with frame number equal -1When acquiring with manual saving mode, then asking for saving the last frame with -1 as frame number does not workWhen acquiring with manual saving mode, then asking for saving the last frame with -1 as frame number does not workv1.9.5Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/lima/-/issues/116Data saving with HDF5 shows low performance2020-06-10T12:01:44+02:00Alejandro Homs PuronData saving with HDF5 shows low performanceWhen performing acquisitions with the Dectris/Eiger2 under X-ray generator photons at ID22, the effective data saving performance is very low:
> The current illumination scheme generate compressed images of ~450 kByte. Under this regim...When performing acquisitions with the Dectris/Eiger2 under X-ray generator photons at ID22, the effective data saving performance is very low:
> The current illumination scheme generate compressed images of ~450 kByte. Under this regime, at 2 kHz frame rate, we found a limiting saving speed on BeeGFS with HDF5-BSLZ4 of ~450 MByte/s (when 900 MByte/s is needed). The interesting news is that we found more or less the same limit saving on one NVME drive, contrary to what we expected
https://gitlab.esrf.fr/limagroup/lima/-/issues/115Memory corruption error after using CtControl::ImageStatusCallback2020-06-29T10:51:13+02:00Alejandro Homs PuronMemory corruption error after using CtControl::ImageStatusCallbackThe [test_int_trig_mult.py](/uploads/d36e153ac5956bac5b46bf922916b115/test_int_trig_mult.py) program systematically shows memory corruption errors with the Simulator, Eiger, and SlsDetector plugins:
```
Valid ranges:
min_exp_time=0.0...The [test_int_trig_mult.py](/uploads/d36e153ac5956bac5b46bf922916b115/test_int_trig_mult.py) program systematically shows memory corruption errors with the Simulator, Eiger, and SlsDetector plugins:
```
Valid ranges:
min_exp_time=0.0000000, max_exp_time=1000000.0000000
min_lat_time=0.0000000, max_lat_time=1000000.0000000
Starting acquisition ...
Sending start #0
Sending start #1
Sending start #2
Sending start #3
Sending start #4
Sending start #5
Sending start #6
Sending start #7
Sending start #8
Sending start #9
Average trigger_delay=0.078 (0.010 + 0.068)
Acquisition finished -0.000 sec after trigger sequence
[2020/06/08 17:31:48.478623] 7fe06f1de740 *Control*Control::Control::unregisterImageStatusCallback (/users/opid00/esrf/sls_detectors/Lima/control/src/CtControl.cpp:1260)-Always: Unregistering 0x557bb770bc40
double free or corruption (out)
```v1.9.5Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima/-/issues/108Usage of [[maybe_unused]] and other C++17 attributes2020-05-20T14:48:53+02:00Samuel DebionneUsage of [[maybe_unused]] and other C++17 attributesThe following discussion from !158 should be addressed:
- [ ] @debionne started a [discussion](https://gitlab.esrf.fr/limagroup/lima/-/merge_requests/158#note_70720): (+8 comments)
> `[[maybe_unused]]` is C++17 but should be harml...The following discussion from !158 should be addressed:
- [ ] @debionne started a [discussion](https://gitlab.esrf.fr/limagroup/lima/-/merge_requests/158#note_70720): (+8 comments)
> `[[maybe_unused]]` is C++17 but should be harmless (even for MSVC) but might generate a warning... which is what you are trying to avoid.https://gitlab.esrf.fr/limagroup/lima/-/issues/106CtControl::m_img_status_thread_list management is not completely thread-safe2021-06-21T17:34:18+02:00Alejandro Homs PuronCtControl::m_img_status_thread_list management is not completely thread-safe`[un]registerImageStatusCallback` hold the lock before modifying the list. Before doing so, the acquisition state must be `AcqReady` (unregister) or different that `AcqRunning` (register).
During `AcqRunning` many methods iterate the li...`[un]registerImageStatusCallback` hold the lock before modifying the list. Before doing so, the acquisition state must be `AcqReady` (unregister) or different that `AcqRunning` (register).
During `AcqRunning` many methods iterate the list after releasing the lock. This is done for performance reasons. In a first approach there should be no big risk here, because taking/releasing the lock forces memory barriers that avoid race conditions.
There are two places with a risk of code iterating the list in parallel to a call to `[un]registerImageStatusCallback`:
1. In the beginning of `prepareAcq`, where no lock is taken
1. At the end of the last call to `_calcAcqStatus`, after setting the state to `AcqReady`.
A possible solution: add a `m_img_status_thread_list_busy` flag.https://gitlab.esrf.fr/limagroup/lima/-/issues/94Video Data-2-Image task is not included in Lima processing state2019-07-09T16:22:00+02:00Alejandro Homs PuronVideo Data-2-Image task is not included in Lima processing state`CtVideo` must be `active` in order to update the data returned by `CtVideo.getLastImage()`. When `active`, an independent task is systematically included in the frame processing pipeline by `CtVideo::frameReady/_data_2_image`. However, ...`CtVideo` must be `active` in order to update the data returned by `CtVideo.getLastImage()`. When `active`, an independent task is systematically included in the frame processing pipeline by `CtVideo::frameReady/_data_2_image`. However, the task status is not taken into account by the acquisition state machine in `CtControl`. This is a potential point of failure because `HW buffers` can be re-allocated before the `Mapped Data's` are consumed.
A possible solution is to modify `CtControl::_calcAcqStatus` to take into account `CtVideo::m_ready_flag` (if `CtVideo::m_active_flag`), and to call it from `CtVideo::_data2image_finished`