FIX(rust): prevent panic when formatting out-of-range timestamps in timing.rs and c_functions.rs

[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.

---

Problem

As reported by @TPeterson94070 in #2100, parsing certain ATSC transport streams from a flaky station causes a fatal panic on v0.96.5 x64 builds:

thread '<unnamed>' panicked at lib_ccxr/src/time/timing.rs:154:160: called `Result::unwrap()` on an `Err` value: OutOfRangeError(TryFromIntError(())) thread caused non-unwinding panic. aborting.

The station intermittently transmits out-of-range PTS values in the video stream. When to_hms_millis_time(':') attempts to format these values it returns Err(OutOfRangeError). Because these results were being directly .unwrap()ed inside debug! and info! logging macros in timing.rs, a formatting failure in a log statement was aborting the entire process.

Solution

Replaced all direct .unwrap() calls on to_hms_millis_time() results with .unwrap_or_else(|_| "INVALID".to_string()) across two files:

• lib_ccxr/src/time/timing.rs
  • set_current_pts() — PTS and FTS debug lines
  • set_fts() — first sync time and new min PTS debug lines
  • print_debug_timing() — sync PTS, GOP time, FTS max, and diff calculation info lines
• lib_ccxr/src/time/c_functions.rs
  • print_mstime_static() — timestamp formatting used by C FFI boundary

No timing logic, sync behavior, or output generation was modified. Only logging and formatting paths are affected.

Testing

Tested locally on macOS ARM64 (Darwin 25.3.0) against FullTS_for_ATSC_ch32_(581MHz)-20sec.ts provided by @TPeterson94070.

	Result
Before fix	Fatal panic at timing.rs:154, process aborts, no XML output generated
After fix	Parser runs to completion, XMLTV output successfully generated

Out of Scope for This PR

• x86 allocation panic: The 32-bit Windows build fails at src/decoder/mod.rs:304 with Failed to allocate dtvcc_service_decoder. This is a separate CEA-708 initialization issue unrelated to this timing fix.
• Orphaned channel="0" XMLTV entries: The output may contain logically orphaned entries arising from inconsistent broadcast metadata in certain EIT sections.

These items are intentionally kept out of scope for this PR to maintain separation of concerns and can be addressed in follow-up work.

[ccextractor-bot]

CCExtractor CI platform finished running the test files on windows. 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	81/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...

Congratulations: Merging this PR would fix the following tests:

• ccextractor --out=spupng c83f765c66..., 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.

[TPeterson94070]

I just tested XMLTV generation with today's x64 and x86 release builds of PR #2138 against a flaky channel full TS. Both failed to complete. The x64 exe said:

thread '<unnamed>' (28864) panicked at lib_ccxr\src\time\c_functions.rs:32:36:
called `Result::unwrap()` on an `Err` value: OutOfRangeError(TryFromIntError(()))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread '<unnamed>' (28864) panicked at library\core\src\panicking.rs:225:5:
panic in a function that cannot unwind
stack backtrace:
   0:     0x7ff6dca6d0c2 - <unknown>
   1:     0x7ff6dca53be1 - <unknown>
   2:     0x7ff6dca617f4 - <unknown>
   3:     0x7ff6dca68fb0 - <unknown>
   4:     0x7ff6dca68dc8 - <unknown>
   5:     0x7ff6dca69222 - <unknown>
   6:     0x7ff6dca690b9 - <unknown>
   7:     0x7ff6dca671cf - <unknown>
   8:     0x7ff6dca6004e - <unknown>
   9:     0x7ff6de092767 - <unknown>
  10:     0x7ff6de0926e1 - <unknown>
  11:     0x7ff6de092896 - <unknown>
  12:     0x7ff6dca3a4e5 - <unknown>
  13:     0x7ff6dde21be0 - <unknown>
  14:     0x7ff6dde20939 - <unknown>
  15:     0x7ff88dd756f6 - RtlCaptureContext2
  16:     0x7ff6dca3a499 - <unknown>
  17:     0x7ff6dce5548a - <unknown>
  18:     0x7ff6dce48998 - <unknown>
  19:     0x7ff6dce47ee3 - <unknown>
  20:     0x7ff6dde19760 - <unknown>
  21:     0x7ff88cdd259d - BaseThreadInitThunk
  22:     0x7ff88dd2af78 - RtlUserThreadStart
thread caused non-unwinding panic. aborting.

And the x86 exe said:

thread '<unnamed>' (27352) panicked at src\decoder\mod.rs:292:21:
Failed to allocate dtvcc_tv_screen
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread '<unnamed>' (27352) panicked at library\core\src\panicking.rs:225:5:
panic in a function that cannot unwind
stack backtrace:
   0:   0x4cae1f - <unknown>
   1:   0x4d76c2 - <unknown>
   2:   0x4dee31 - <unknown>
   3:   0x4dec51 - <unknown>
   4:   0x4df0b1 - <unknown>
   5:   0x4def53 - <unknown>
   6:   0x4dd20b - <unknown>
   7:   0x4d5fb0 - <unknown>
   8:  0x15a03af - <unknown>
   9:  0x15a031a - <unknown>
  10:  0x15a0496 - <unknown>
  11:   0x49a13f - <unknown>
  12:   0x72f77d - <unknown>
  13:   0x758063 - <unknown>
  14:   0x7525c9 - <unknown>
  15:   0x71a6fe - <unknown>
  16:   0x71a376 - <unknown>
  17:  0x1399ba1 - <unknown>
  18: 0x760b7ba9 - <unknown>
  19: 0x77d7c3ab - <unknown>
  20: 0x77d7c32f - <unknown>
thread caused non-unwinding panic. aborting.

The full transcript is here: Windows PowerShell 260223.zip

[x15sr71]

@TPeterson94070, Thanks for testing with a new flaky sample and sharing logs, I've pushed a fix for the c_functions.rs:32 panic - same root cause as the earlier timing.rs fix. Could you test the updated build against the sample that triggered this failure? If it passes, I'll mark the PR ready for review. If you have additional flaky captures handy, testing those too would be helpful, as any new failures can be folded into this PR before it goes for review.

P.S.: This update addresses the timestamp formatting panics (timing.rs and c_functions.rs). The 32-bit x86 allocation failure in decoder/mod.rs is a separate issue and is not affected by this PR, as noted in the description. That will require a dedicated follow-up investigation and fix.

[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	81/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...

Congratulations: Merging this PR would fix the following tests:

• ccextractor --out=spupng c83f765c66..., 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.

[TPeterson94070]

Using today's release x64 and x86 builds, I ran XMLTV tests on two FullTS files that fail on earlier ccextractor builds. The x64 build succeeded on both and the x86 build failed. IIUC, the x86 build failure is expected with this PR. Here is the transcript:
Windows PowerShell (26-02-24).zip

And here are links to the two TS files: FullTS_for_ATSC_ch32_(581MHz)-20sec 26-02-23.ts
FullTS for ATSC ch32 (581MHz)-20sec 26-02-20.ts

[x15sr71]

@TPeterson94070 Yes, that’s correct, x64 is fixed by this PR, and the x86 failure is a separate issue. Thanks for confirming.