Do you try with monochrome file? Color file?
Do you debayer on-the-fly?
I use a SER file coming from ZWO asi224mc. I did a SER file for the dark. I can create the dark.fit with 0.99.4 version.
I did nothing during the night. Just record raw data.
I have created the dark with median stack.
I open the SER and I check that dematrix is not selected. I select the dark.fit. I remove cosmetic correction. And after clicking on pre process, Siril shut down after 1-2 seconds without any message.
I don’t know where I can find a log
I have this issue from the first day I have installed 0.99.4
Is your dark.fit monochrome? (i.e single channel?)
Because you need it for preprocessing.
Yes. No dematrix when I create the dark.
The same things are working well on 0.9.
I use Windows 10
Could you try with this version ?
https://gitlab.com/free-astro/siril/-/jobs/735047803/artifacts/download
I will do it and come back to you. I understand you are french (as me) and I wonder in which forum you collect data for debug of the 0.99
Samuel
Tested after replacing all the files with your package. Same result. Immediate shut down
if you could share your master and your ser file please.
I have extracted only 20 pictures of the SER and export in a new SER file.
Here is the link to download the SER file and the dark.fit. I have checked, still an issue with only 20 pictures.
https://we.tl/t-PVlRjBagUp
Thanks for your help if I’m doing a wrong action in 0.99, but it works well in 0.9
Regards
It works here:
21:02:23: Preprocessing...
21:02:23: Created SER file pp_test_Siril.ser
21:02:23: Number of images allowed in the FITS write queue: 24 (zero or less is unlimited)
21:02:23: 42376 corrected pixels (0 + 42376)
21:02:23: Preprocessing: processing...
21:02:23: writer: Saving image 0, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 1, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 2, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 3, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 4, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 5, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 6, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: Sequence processing succeeded.
21:02:23: Execution time: 196.52 ms.
21:02:23: writer: Saving image 7, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 8, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 9, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 10, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 11, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 12, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 13, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 14, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 15, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 16, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 17, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 18, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: writer: Saving image 19, 1 layer(s), 1304x976 pixels, 16 bits
21:02:23: Saved 20 images in the sequence
21:02:23: Number of images allowed in the FITS write queue: 0 (zero or less is unlimited)
21:02:23: Sequence loaded: pp_test_Siril (0->19)
21:02:23: Closing sequence /home/cyril/Bureau/test_Siril/test_SirilVery strange. An issue with my computer configuration? Do you know if I can find a log somewhere to see what happens?
I always have this issue whatever the entry data… thanks
Hello, I have tested again and in fact I used the 0.99.4! My shortcut pointed on the wrong version.
With 0.99.5, it’s ok now 
Thanks
Samuel
1 Like
Nice.
however this version has a known bug with ser files and indices.
@vinvin work on it, we’ll let you know.
On macOS I’ve also detected another “bug” (or at least estrange behaviour): it detects 8 kernels on my CPU but it only uses one, so it’s very slow compared with the last versions when registering / stacking frames (I’m using beta version on macOS 10.15.6)
How do you know it only uses one core?
Do you have any message in log about cfitsio not being reentrant?
After some months using your last “private” build on macOS, I’ve got the rhytme of multiple kernels processing a sequence (multiple load / aligning printed on log vs a one by one on this beta). Anyway, I’ve taken a look at the console and I’ve got the following data. When Siril start:
14:42:41: Welcome to siril v0.99.4
14:42:41: Supported file types: BMP images, PIC images (IRIS), PGM and PPM binary images, RAW images, FITS-CFA images, Films, SER sequences, TIFF images, JPG images, PNG images, HEIF images.
14:42:41: Loading init file: ‘/Users/rlbe/Library/Application Support/siril/siril.config’
14:42:41: Parallel processing enabled: Using 8 logical processors.
But latter, as I open and stack one sequence, I’ve read this other message:
14:45:06: Stacking: processing…
14:45:06: Processing all images in the sequence (10)
14:45:06: Stacking result will be stored as a 32-bit image
14:45:06: Computing normalization…
14:45:06: Reading FITS: file Jupiter_Flat_0.100_secs_001.fits, 1 layer(s), 3888x2592 pixels
14:45:06: Reading FITS: file Jupiter_Flat_0.100_secs_002.fits, 1 layer(s), 3888x2592 pixels
14:45:08: Reading FITS: file Jupiter_Flat_0.100_secs_003.fits, 1 layer(s), 3888x2592 pixels
14:45:09: Reading FITS: file Jupiter_Flat_0.100_secs_004.fits, 1 layer(s), 3888x2592 pixels
14:45:10: Reading FITS: file Jupiter_Flat_0.100_secs_005.fits, 1 layer(s), 3888x2592 pixels
14:45:11: Reading FITS: file Jupiter_Flat_0.100_secs_006.fits, 1 layer(s), 3888x2592 pixels
14:45:12: Reading FITS: file Jupiter_Flat_0.100_secs_007.fits, 1 layer(s), 3888x2592 pixels
14:45:13: Reading FITS: file Jupiter_Flat_0.100_secs_008.fits, 1 layer(s), 3888x2592 pixels
14:45:14: Reading FITS: file Jupiter_Flat_0.100_secs_009.fits, 1 layer(s), 3888x2592 pixels
14:45:15: Reading FITS: file Jupiter_Flat_0.100_secs_010.fits, 1 layer(s), 3888x2592 pixels
14:45:16: Not using limits on maximum memory for stacking
14:45:16: Your version of cfitsio does not support multi-threading
14:45:16: We have 4 parallel blocks of size 648 (+0) for stacking.
By the way, the standard macOS keyboard shortcut for “copy” from the logs (command+C) is not working (instead, the function is mapped to control+C)
This is the issue.
Do you have the official beta release? In this case I don’t know why you have this because I should have built with re-entrant option. Need to investigate but not before next week as I’m on business trip.
Do you have the official beta release?
Yes I do. To double check, I’ve removed it and downloaded again the latest beta from siril.org and yet I’ve observed the same behaviour
15:35:57: Your version of cfitsio does not support multi-threading
That’s the reason I was warning you, because this was a public beta 
And I really don’t know why: