[Fix]: SPUPNG indexing, EOD counter advance, and header path determinism

[x15sr71]

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

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.
• I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

• I have never used CCExtractor.
• I have used CCExtractor just a couple of times.
• I absolutely love CCExtractor, but have not contributed previously.
• I am an active contributor to CCExtractor.

---

SPUPNG: Fix file indexing, EOD counter advance, and header path determinism

Three correctness fixes in the SPUPNG encoder. These are independent of each other but all live in the same file.

1. File numbering corrected: first file is now sub0000 instead of sub0001

fileIndex was initialized to 0, but inc_spupng_fileindex() increments before writing, so the first file was always sub0001.png. The CCExtractor SPUPNG docs specify numbering starts at sub0000.png.

Fix: initialize fileIndex to -1 so the first increment lands at 0.

2. Index advances on EOD frames with no output

inc_spupng_fileindex() was called before the nb_data == 0 && SUB_EOD_MARKER early-return in write_cc_bitmap_as_spupng(). The counter advanced even though no PNG was written, creating gaps. Moved the increment past the early-return.

3. XML header comment embeds full runtime path

spupng_write_header() wrote the full input path into the XML comment. Windows CI produces .\TestFiles\... while the golden uses /repository/TestFiles/... — they can never match. Changed to basename only.

---

Note on golden: The golden for sample121/c83f765c... predates PR #1850 (offset correction) and subsequent timing fixes. As a result, its offsets and timestamps do not match current master output and will require regeneration.

[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 6f7ce27...:

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

Your PR breaks these cases:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2...
• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65...
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b...
• 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...

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

• ccextractor --out=spupng c83f765c66..., Last passed:

  Test 8454

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.