D20029: Capture counting corrected

[Wolfgang Reissenberger]

wreissenberger added a comment.


  > It's unclear, but maybe, yes.
  
  Agreed, the issue we are working here is a good hint. I asked for more details on the forum.
  
  > Could I offer my own implementation on the two fixes that are in this differential? I'd like to first fix the FindNextJob issue, then in another diff the frame counting via messages from the capture module.
  
  Absolutely fine, I do not have the ambition that I fix it. I simply want it to be fixed asap. :-)
  
  > My previous message is about the calculation : the order of operators produces 1 when less than a full sequence is executed. It also considers sequences are distributed equally between jobs, which I disagree with as the code, in remember mode, is trying to gather frames to complete sequences in order, then schedule remaining ones.
  
  You are right, the calculation of captured frames of a certain sequence job is only correct as long as the entire capture job has completed. If it does not run completely, the frames taken in the last cycle are not counted correctly.
  Let's take an example with a LLLRGB sequence that completes twice and terminates after two L frames. In the calculation, we have `schedJob->getCompletedCount() = 14`, `capturesPerRepeat=6` and `seqJob->getCount() = 3`. As a result we get `14/6*3 = 6` - which is wrong, it should be 8.
  
  Nevertheless, it is by far better than the current situation, where the result would be 14.
  
  Personally, I would recommend to apply this diff and fix the counting in a subsequent one. If we want to do it perfectly right, we need to use the capturedFramesMap, so that a captured frame is documented properly. But this requires some effort.

REPOSITORY
  R321 KStars

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

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