[ideacobra]

Why

Two small but real bugs turned up during a code review pass over model/, webui/, and finetune*/:

1. webui/app.py: In save_prediction_results, the continuity-analysis block (which computes last_prediction, first_actual, gaps, and gap percentages) was indented one level too shallow. first_actual and the save_data['analysis']['continuity'] assignment sat outside the if len(prediction_results) > 0 and len(actual_data) > 0 guard, even though they reference last_pred, which is only defined inside that guard. Whenever actual_data was present but prediction_results was empty, this raised a NameError. Because the whole function body is wrapped in a broad try/except, the error was swallowed silently and prediction results simply failed to save, with only a generic log message.

2. finetune_csv/finetune_tokenizer.py: The end-of-epoch summary logs both "Epoch Time" and "Total Training Time", but both were computed from the same epoch_start_time, which is reset at the top of every epoch loop iteration. As a result, "Total Training Time" always equaled "Epoch Time" instead of accumulating across the whole run, making the logged totals misleading. The sibling script finetune/train_tokenizer.py does this correctly by tracking a separate start_time captured once before the epoch loop; this change brings finetune_csv/finetune_tokenizer.py in line with that pattern.

What changed

• webui/app.py: Re-nested first_actual and the continuity dict assignment inside the if len(prediction_results) > 0 and len(actual_data) > 0 block so last_pred/first_actual are always defined before use. No behavioral change to the analysis logic itself, just the control flow.
• finetune_csv/finetune_tokenizer.py: Added start_time = time.time() once before the epoch loop in train_tokenizer, and changed the "Total Training Time" log line to use start_time instead of epoch_start_time.

Verification

• Both files pass python3 -m py_compile.
• Manually exercised save_prediction_results with stubbed dependencies for both the previously-crashing case (empty prediction_results with non-empty actual_data) and the normal case (both present), confirming no NameError and correct gap_percentages output.