FIX(rust): prevent panic when formatting out-of-range timestamps in timing.rs and c_functions.rs by x15sr71 · Pull Request #2138 · CCExtractor/ccextractor

x15sr71 · 2026-02-23T20:53:42Z

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.

TPeterson94070 · 2026-02-23T22:28:12Z

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

…t-of-range timestamps

x15sr71 · 2026-02-24T12:50:08Z

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

TPeterson94070 · 2026-02-24T18:50:11Z

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 · 2026-02-25T12:11:52Z

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

x15sr71 · 2026-02-25T19:55:09Z

@TPeterson94070 I’ve pushed a separate commit in my fork with the allocation fix, and CI has produced a new x86 (32-bit) build. I don’t have access to a Windows 32-bit setup on my side, so I’m not able to test the x86 binary directly. Could you please try this artifact with the same flaky TS file that previously failed?

Artifact:
https://github.com/x15sr71/ccextractor/actions/runs/22410871311/artifacts/5660179963

TPeterson94070 · 2026-02-25T21:11:20Z

@x15sr71, sorry, today's build also failed those files. Here's the transcript:
Windows PowerShell (26-02-25).zip

BTW, you can run the 32-bit exe on a Windows 64-bit OS (which is what I just did).

TIMING_PATCH_ACTIVE was a temporary diagnostic string added to verify that GitHub Actions was building fresh artifacts from the correct branch commit, and not serving a stale cached binary. Build freshness was confirmed. Reverted back to INVALID.

ccextractor-bot · 2026-02-27T15:40:11Z

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

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

Congratulations: Merging this PR would fix the following tests:

ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed: Never
ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65..., Last passed: Never
ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b..., Last passed: Never
ccextractor --out=spupng c83f765c66..., Last passed: Never
ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never

All tests passed completely.

Check the result page for more info.

ccextractor-bot · 2026-02-27T16:01:45Z

CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 733ed89...:

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

Congratulations: Merging this PR would fix the following tests:

ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed: Never
ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65..., Last passed: Never
ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b..., Last passed: Never
ccextractor --out=spupng c83f765c66..., Last passed: Never
ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never

All tests passed completely.

Check the result page for more info.

x15sr71 added 2 commits February 24, 2026 01:00

fix(rust): prevent panic in timing.rs when formatting invalid timestamps

ef33eb8

docs: add changelog entry

10c612f

x15sr71 marked this pull request as draft February 23, 2026 21:30

fix(rust): replace unwrap in print_mstime_static to avoid panic on ou…

9039c80

…t-of-range timestamps

x15sr71 changed the title ~~FIX(rust): prevent panic when formatting out-of-range timestamps in timing.rs~~ FIX(rust): prevent panic when formatting out-of-range timestamps in timing.rs and c_functions.rs Feb 25, 2026

x15sr71 marked this pull request as ready for review February 25, 2026 12:09

x15sr71 added 2 commits February 27, 2026 18:35

debug: add a small sentinel string to check if the artifact is fresh

f5cede7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

FIX(rust): prevent panic when formatting out-of-range timestamps in timing.rs and c_functions.rs#2138
x15sr71 wants to merge 5 commits intoCCExtractor:masterfrom
x15sr71:fix/rust-timing-unwrap-panic

x15sr71 commented Feb 23, 2026 •

edited

Loading

Uh oh!

TPeterson94070 commented Feb 23, 2026

Uh oh!

x15sr71 commented Feb 24, 2026 •

edited

Loading

Uh oh!

TPeterson94070 commented Feb 24, 2026

Uh oh!

x15sr71 commented Feb 25, 2026

Uh oh!

x15sr71 commented Feb 25, 2026 •

edited

Loading

Uh oh!

TPeterson94070 commented Feb 25, 2026 •

edited

Loading

Uh oh!

ccextractor-bot commented Feb 27, 2026

Uh oh!

ccextractor-bot commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

x15sr71 commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Testing

Out of Scope for This PR

Uh oh!

TPeterson94070 commented Feb 23, 2026

Uh oh!

x15sr71 commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TPeterson94070 commented Feb 24, 2026

Uh oh!

x15sr71 commented Feb 25, 2026

Uh oh!

x15sr71 commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TPeterson94070 commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ccextractor-bot commented Feb 27, 2026

Uh oh!

ccextractor-bot commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

x15sr71 commented Feb 23, 2026 •

edited

Loading

x15sr71 commented Feb 24, 2026 •

edited

Loading

x15sr71 commented Feb 25, 2026 •

edited

Loading

TPeterson94070 commented Feb 25, 2026 •

edited

Loading