D14684: [DO NOT MERGE YET] Fix duplicate sequence jobs completion checks.

[Eric Dejouhanet]

TallFurryMan added a comment.


  In D14684#305563 <https://phabricator.kde.org/D14684#305563>, @mutlaqja wrote:
  
  > 1. The capture bar is showing 100% as soon as it starts then goes to normal. Bar should advanced _after_ an image is captured, not before/during since it's confusing to see 100% and still capturing last image.
  > 2. Capture logs says 2018-08-09T09:43:11 Job requires 5-second Red images, has 5/0 frames captured and will be processed. which probably needs to be reversed 0/5
  > 3. Capturing 5-second Red image... --> not sure about format here. I think the dash needs to be dropped. Capturing 5 seconds image. Maybe need to use i18np for singular/plural case but it's double value so that might be tricky.
  
  
  
  
  1. I can't reproduce that in the latest diff if we're talking about the Capture module progress bar. There is, however, a concurrency when using 1-second captures which causes the progress to remain at 100% while processing single-capture sequence jobs, but that's very elusive. With greater exposures I don't see the issue. If actually it shows up on lower-end computers I'll have a look, please tell me.
  2. Fixed
  3. I'll leave it like this, please tell me if you think otherwise. That construct has the advantage to bypass the management code for plurals :)
  
  In D14684#306156 <https://phabricator.kde.org/D14684#306156>, @wreissenberger wrote:
  
  > Not sure whether the problem still exists after your changes, but I found a situation where the scheduler loops endlessly.
  >  If you have two jobs with the same capture file signature (path + filter etc.) and the **second** has **less** repeats than the first, the first job will repeat endlessly.
  >  The problem is that Scheduler::updateCompletedJobsCount() overwrites the map entry such that a later evaluation thinks that it has less captures than requested.
  
  
  Aha, let's have a look into this, thanks. I did actually check for this situation in a more general manner, that is, code should not presume of the order in which the scheduler jobs are sorted in the list, but I should have built a test vector.
  -Eric

REPOSITORY
  R321 KStars

REVISION DETAIL
  https://phabricator.kde.org/D14684

To: TallFurryMan, mutlaqja, wreissenberger
Cc: kde-edu, narvaez, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20180810/758af4f3/attachment-0001.html>