fix(608): only apply pop-on→roll-up EOF fallback when start time is unset

[x15sr71]

In raising this pull request, I confirm the following (please check boxes):

Reason for this PR:

• This PR adds new functionality.
• This PR fixes a bug that I have personally experienced or that a real user has reported and for which a sample exists.
• This PR is porting code from C to Rust.

Sanity check:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• If the PR adds new functionality, I've added it to the changelog. If it's just a bug fix, I have NOT added it to the changelog.
• I am NOT adding new C code unless it's to fix an existing, reproducible bug.

Repro instructions:

This PR fixes Regression Test 11, which fails on master on both Windows and Linux. On Linux, it currently shows a separate “No output generated but there should be” issue that is still under investigation; Reference test run - Windows, Linux.

---

Problem

A 608 regression caused incorrect cue start times on a WTV sample, while subtitle text and end times remained correct.

Root cause

689b27ce added an EOF fallback for pop-on -> roll-up transitions by back-filling current_visible_start_ms from ts_first_char_rollup_transition.

That fallback was too broad: if rollup_from_popon was still set when write_cc_buffer() ran, it could overwrite an already valid current_visible_start_ms with the first-character FTS.

Fix

Only apply the EOF fallback when current_visible_start_ms is still unset:

if (context->rollup_from_popon &&
    context->ts_first_char_rollup_transition > 0 &&
    context->current_visible_start_ms <= 0)

This keeps the EOF fix from 689b27ce while avoiding clobbering valid cue start times on normal paths.

Testing

• Reproduced the regression on the affected WTV sample - 611b4a9235c08....
• Applied the guard above in write_cc_buffer().
• Rebuilt CCExtractor and compared the generated SRT against the reference file.
• Verified that the diff between current output and the reference file (2af8168380d0...) is clean.

[ccextractor-bot]

CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 2feb09a...:

Report Name	Tests Passed
Broken	10/13
CEA-708	2/14
DVB	1/7
DVD	3/3
DVR-MS	2/2
General	23/27
Hardsubx	1/1
Hauppage	3/3
MP4	3/3
NoCC	10/10
Options	72/86
Teletext	20/21
WTV	13/13
XDS	31/34

Your PR breaks these cases:

• ccextractor --autoprogram --out=ttxt --latin1 1020459a86...
• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2...
• ccextractor --autoprogram --out=ttxt --latin1 99e5eaafdc...
• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65...
• ccextractor --autoprogram --out=ttxt --latin1 01509e4d27...
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b...
• ccextractor --out=spupng c83f765c66...
• ccextractor --dru c83f765c66...
• ccextractor --startat 4 --endat 7 c83f765c66...
• ccextractor --codec dvbsub --out=spupng 85271be4d2...
• ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --autoprogram --out=srt --latin1 --ucla d037c7509e...
• ccextractor --autoprogram --out=srt --latin1 --ucla 7d3f25c32c...
• ccextractor --autoprogram --out=ttxt --latin1 --ucla --xds 7f41299cc7...

NOTE: The following tests have been failing on the master branch as well as the PR:

• ccextractor --out=srt --latin1 --autoprogram 73d9313d64..., Last passed:

  Test 8738

• ccextractor --out=ttxt --latin1 001dd8cdf7..., Last passed:

  Test 8738

• ccextractor --out=srt --latin1 4d4e938ef6..., Last passed:

  Test 8738

• ccextractor --service 1 --out=txt --no-bom --no-rollup ea83ff7bcb..., Last passed:

  Test 8738

• ccextractor --service 1 --out=txt f17524b53f..., Last passed:

  Test 8738

• ccextractor --service 1 --out=txt 80848c45f8..., Last passed:

  Test 8738

• ccextractor --service 1 --out=txt --no-bom --no-rollup b5d6aad89f..., Last passed:

  Test 8738

• ccextractor --service 1[EUC-KR] --out=txt --no-rollup b5d6aad89f..., Last passed:

  Test 8738

• ccextractor --service 1 --out=srt da904de35d..., Last passed:

  Test 8738

• ccextractor --service 1 --out=sami da904de35d..., Last passed:

  Test 8738

• ccextractor --service 1[EUC-KR] b5d6aad89f..., Last passed:

  Test 8738

• ccextractor --service 1[EUC-KR] --no-rollup b5d6aad89f..., Last passed:

  Test 8738

• ccextractor --service all da904de35d..., Last passed:

  Test 8738

• ccextractor --service all[EUC-KR] b5d6aad89f..., Last passed:

  Test 8738

• ccextractor --service 1,2[UTF-8],3[EUC-KR],54 --out=txt da904de35d..., Last passed:

  Test 8738

• ccextractor --autoprogram --out=srt --latin1 f1422b8bfe..., Last passed:

  Test 9208

• ccextractor --autoprogram --out=srt --latin1 d41b53b504..., Last passed:

  Test 8738

• ccextractor --stdout --quiet --no-fontcolor 79a51f3500..., Last passed:

  Test 8738

• ccextractor --stdout --quiet --no-fontcolor 767b546f96..., Last passed:

  Test 8738

• ccextractor --service 1 c83f765c66..., Last passed:

  Test 8738

• ccextractor --myth c83f765c66..., Last passed:

  Test 8738

• ccextractor --in=raw fb79021542..., Last passed:

  Test 8738

• ccextractor --mp4vidtrack 5df914ce77..., Last passed:

  Test 8738

• ccextractor --xmltv=3 --out=null 96efd279cf..., Last passed:

  Test 8738

• ccextractor --datapid 2310 --autoprogram --out=srt --latin1 e639e54550..., Last passed:

  Test 8738

Congratulations: Merging this PR would fix the following tests:

• ccextractor --service 1 --out=ttxt da904de35d..., Last passed: Never
• ccextractor --autoprogram --out=ttxt --latin1 132d7df7e9..., Last passed: Never
• ccextractor --autoprogram --out=srt --latin1 b22260d065..., Last passed: Never

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

[cfsmp3]

I applied this change onto current master (the branch base is from July, so building it directly would confound the comparison) and compared RT11's output against its approved baseline. It moves away from the baseline rather than toward it:

	mismatching cue times vs approved
master	3
master + this PR	4

The regression is cue 25:

approved:  00:01:52,446 --> 00:01:57,583
master:    00:01:52,446 --> 00:01:57,583   (matches)
this PR:   00:01:25,219 --> 00:01:57,583   (32 seconds)

Master already gets that cue exactly right, and the guard makes it start 2 ms after cue 24 ends and run for 32 seconds — for [ BIRDS CHIRPING ] / [ DOG BARKS ]. Cue 26 also moves further away, from 68 ms off to 3.2 s off.

The underlying reasoning is right — a fallback that overwrites an already-valid current_visible_start_ms is wrong — but current_visible_start_ms <= 0 is not the condition that distinguishes the two cases. On this sample the value is already set at the point the fallback runs, and the fallback was what made it correct.

One process note: the platform runs cited (9350/9351) predate the baseline fix in sample-platform#1175, so at the time a PR's red/green on the suite was partly determined by which run preceded it. Worth re-running against a current baseline before drawing conclusions from those numbers.

Happy to look again if you have a sample where the current guard demonstrably helps — the diff itself is small and the intent is clearly right.

@x15sr71

[x15sr71]

Agreed, closing — I'd already left this in draft with the same doubt, and your numbers settle it.

Thanks for re-running against a current baseline — that's conclusive. You're right that current_visible_start_ms <= 0 isn't the discriminator; the value is already set by the time the fallback runs, so the guard skips the assignment that was making cue 25 correct.

Appreciate the offer to look again, but I don't have a sample where the guard demonstrably helps.

I'm still working the underlying timing issue, specifically RT84 and RT11, which both fail on current master. I have a candidate and I'm validating it against the ~165 regression tests I have samples for on my Linux box; if it holds up across the suite I'll open a PR right away.