Skimming needs to know NHBPERTF, extract from ALIEN_JDL_LPMRUNNUMBER

[shahor02]

@chiarazampolli @mpuccio the TFs with no data in the skimmed CTFs corresponded to TFs for which nothing was selected but the following 3TFs had something selected. The reason is that we did not set from the command line the NHBFPERTF (via HBFUTILS), as a result, the workflow was taking default 128 HBF. So, the ctf-reader was seeing something selected for the [1st_orbit : 1st_orbit+128] but detector encoders did not find any selected BC overlapping with the TF being processed and were writing empty CTF. Effectively, the --skip-skimmed-out-tf was not working for most of TFs, but this should be fully transparent for further processing.
The corruption reports is something else, still debugging.

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass3
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0

[chiarazampolli]

Thanks @shahor02 , do we need some further review, or should I merge?
To be understood how 2023 worked, since it is also with 128 orbits per TF.

[shahor02]

@chiarazampolli all 2023 has the same problem: many TFs rejected by the trigger are stored with 0 data, but this does not pose any problem (except ~1% increase of the new CTF size).