Challenge 2: Why Check the Stats Dock Before Recording, Not After — Solution Walkthrough

Why checking beforehand is the better approach:

Per Chapter 8's own material, checking the Stats Dock is the actual
diagnostic starting point for catching a problem like encoding
overload before it affects the recording at all. If a problem like
CPU/encoder overload is caught before recording starts, it can be
fixed (switching encoders, lowering resolution, closing other
applications) with zero cost — nothing has been recorded yet that
could be ruined.

Why checking only afterward is genuinely worse:

If the same problem were only discovered by reviewing the finished
file afterward, the entire session's recording could already be
affected by dropped frames or encoding artifacts baked directly into
the file — a problem that, unlike a pre-recording check, cannot be
undone after the fact. The tutorial session would likely need to be
redone entirely, at real cost in time.

Why this matches the capstone's own reasoning directly:

Step 8 explicitly frames this check as "catching a potential encoding-
overload problem before it ever affects the actual session, rather
than discovering it partway through" — checking beforehand turns a
potentially costly, unrecoverable mistake into a cheap, easily fixed
one.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies Chapter 8's own Stats-Dock material to the
capstone's own specific sequencing choice, correctly explaining why a
pre-recording check is strictly better than a post-recording review
for this particular kind of problem.