Bugfix: proper usage of abort() for finishing a capture sequence queue
ClosedPublic

Authored by wreissenberger on Mar 17 2019, 6:41 PM.

Details

Summary

Before diff D19528, abort events in the capture module where not always communicated to the scheduler. As a result, an aborted guiding was never restarted and brought the scheduler and the capture module out of sync. The scheduler thought that the capture was running while it already had been aborted.

Unfortunately, the Capture::abort() function is also used for properly terminating a capture session. If a capture session has been completed, stop() is called and then abort(), resulting in an unexpected abort event in the scheduler.

If a scheduler restarts a capture session, this abort event from the previous run leads to the situation, that Capture::start() is called twice, which leads to the situation that the first entry of the capture sequence is skipped.

Test Plan
  • Create a capture session with at least two entries.
  • Create a schedule that uses this session and runs at least twice.
  • Start the schedule and check, whether in the second run of the capture session all session entries are executed properly. Without this diff, the first session entry is skipped except for the first run. With this diff, everything should work properly.

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.
wreissenberger created this revision.Mar 17 2019, 6:41 PM
Restricted Application added a project: KDE Edu. · View Herald TranscriptMar 17 2019, 6:41 PM
Restricted Application added a subscriber: kde-edu. · View Herald Transcript
wreissenberger requested review of this revision.Mar 17 2019, 6:41 PM
mutlaqja accepted this revision.Mar 18 2019, 5:08 AM
This revision is now accepted and ready to land.Mar 18 2019, 5:08 AM
This revision was automatically updated to reflect the committed changes.