| Summary: | Sequence jobs with "filter" suffix see less captures than sequence jobs without | ||
|---|---|---|---|
| Product: | [Applications] kstars | Reporter: | TallFurryMan <eric.dejouhanet> |
| Component: | general | Assignee: | TallFurryMan <eric.dejouhanet> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | mutlaqja |
| Priority: | NOR | ||
| Version First Reported In: | git | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Session log, see the very end of the file for details | ||
I'll take this one. Perhaps we can turn this into a feature, but only if that's not too much of a headache for users... We can't turn this into a feature: if the sequence jobs are requiring different exposure times, the enumeration is wrong. To fix this properly, we should remove the option to add those suffixes, and unconditionally add those suffixes to all captures. Consider a sequence job that takes 1-, 5- and 10-second captures with the same filter. If "Duration" is not enabled, there is no way to differentiate the capture files other than looking into the FITS header. It means that the Scheduler will not be able to associate those captures with their corresponding sequence job item. If the scheduler job is run successfully in one single iteration, no issue, sequence job items will be taken in the right order. Now if the end-user deletes one of the 5-second captures, the Scheduler will not be able to determine that the 5-second sequence is missing one image because all images are named "Light_xxx.fits". Right now the fix for this issue is to unconditionally add suffixes "Filter" and "Duration" to all captures. Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |
Created attachment 114467 [details] Session log, see the very end of the file for details Consider the processing of two identical scheduler jobs, using similar sequence jobs, capturing to the same storage folder, but one with "filter" suffix enabled and one with "filter" suffix disabled. When executed on a storage that already contains captures, the scheduler will associate less of those captures to the sequence job that has "filter" suffix enabled than to the sequence job that has "filter" suffix disabled. This happens because the capture recognition is processed by checking the beginning of the string. The sequence job without the "filter" suffix will match the captures with the "filter" suffix, but the sequence job with the "filter" suffix will not match the captures without the "filter" suffix.