When a job completes, capture storage cache is incoherent if job is re-evaluated later than others.
Does NOT fix the regression on sequences embedding duplicated frame types, which cause counts to be incorrect when transferred to Capture.
Details
Details
Test duplicated jobs. When a job finishes, subsequent jobs must not cause the finishing job to loop indefinitely.
Diff Detail
Diff Detail
- Repository
- R321 KStars
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Looks good, my test cases with the duplicated schedule are running now. Two minor things that I found, but they are not critical:
- Having two jobs with the same signature both with FINISH_REPEATand the second to run has less cycles than the first one, the second is started and finishes after one iteration. But I think this not a behavior introduced with this fix. Just to be mentioned...
- When creating newFramesCountthere is no check whether it already contains the signature to be evaluated. This leads to duplicated calls to getCompletedFiles(). Functionally this is OK, but it makes the check slower.
Comment Actions
Ah, yes. Probably a regression or a side-effect of an older change. This use case is a bit weird (but possible of course), perhaps we should order duplicates per repeat count?
Also, I'm weighting the possibility to reorder the jobs in the list per startup order, so that it's clearer for the end-user which one will start before the other.
- When creating newFramesCountthere is no check whether it already contains the signature to be evaluated. This leads to duplicated calls to getCompletedFiles(). Functionally this is OK, but it makes the check slower.
Agreed. Perhaps I can add a check right now.
Comment Actions
- Avoided counting captures for signatures already counted, now that cache is more coherent.
Comment Actions
This happens also if you have two identical cycle numbers. The second one starts once and detects after one cycle that it is completed. It seems like there is no check that jobs once scheduled might get completed without a single run.
- When creating newFramesCountthere is no check whether it already contains the signature to be evaluated. This leads to duplicated calls to getCompletedFiles(). Functionally this is OK, but it makes the check slower.
Agreed. Perhaps I can add a check right now.
OK, checked, working.
Comment Actions
Thanks! Now I need to revisit another differential I made to fix the capture storage, because it was trying to work around an issue with the wrong fix.
Issue is apparent when testing with vector "duplicated_scheduler_jobs_duplicated_sequence_jobs_no_twilight".
The count of captured frames is wrong for the second R sequence job, and the third scheduler job, supposed to be run twice, is not running.
But hey wait that's my fault, I left D14928 without answer!! I'm so sorry about this, I was certain this differential was merged. Let me test this as soon as possible.