[Kst] [Bug 104765] skipping frames in live data causes mysterious 'retrace line' to appear randomly

Andrew Walker arwalker at sumusltd.com
Fri May 13 01:58:45 CEST 2005


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=104765         




------- Additional Comments From arwalker sumusltd com  2005-05-13 01:58 -------
I believe this problem is caused by a bug in KstRVector::doUpdate(...) in the following section of code:

  if (DoSkip) {
    // change new_f0 and new_nf so they both lie on skip boundaries
    //tmp_fn = ((new_f0 + new_nf)/Skip) * Skip - 1;
    tmp_fn = new_f0 + new_nf - 1;
    // new_f0 == 0 results in (new_f0 - 1)/Skip being -0.x which rounds the
    // wrong way on us.  Therefore new_f0 == 0 is a special case.
    new_f0 = new_f0 == 0 ? 0 : (((new_f0 - 1)/Skip) + 1) * Skip;
    new_nf = tmp_fn - new_f0 + 1;
  }

The problem is that if new_f0 is 0 then new_nf always remains unchanged, which is not the desired effect. It not only produces the reported bug, but also causes the entire vector to be reset at regular intervals. Unless I hear otherwise I'll check in the following:

  if (DoSkip) {
      if (new_f0 != 0) {
        new_f0 = (((new_f0-1)/Skip)+1)*Skip;
      }
      new_nf = (new_nf/Skip)*Skip;
  }

It's probably worth noting that there is another bug, in that if you specify a starting frame of 2 (for example) together with reading 1 sample per 5 frames (for example), you actually get a starting of frame 5. Not a major problem, but not what was asked for. This should also be simple to fix, but does change the current behaviour. Opinions?


More information about the Kst mailing list