Skip to content

fix: Correct progress time display for multi-program TS files #2007

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
cfsmp3 merged 1 commit into from
Jan 11, 2026
Merged

fix: Correct progress time display for multi-program TS files #2007

cfsmp3 merged 1 commit into from
Jan 11, 2026
+42 −1

Conversation

@cfsmp3
Copy link
Contributor

@cfsmp3 cfsmp3 commented Jan 10, 2026

Summary

  • Fixes incorrect progress time display for multi-program transport stream files
  • Times now show correctly relative to file start instead of wildly jumping values

Problem

Multi-program TS files can have different PCR (Program Clock Reference) bases for each program. For example:

  • Program A: PCR base at 23 hours
  • Program B: PCR base at 25 hours

When processing such files, the progress time would jump between values based on which program's data was being processed:

1%  |  265:45  (from Program B)
2%  |  00:00   (from Program A)
3%  |  263:11  (from Program B)
...

This was confusing for a 6-second file!

Solution

Track the minimum timestamp offset seen across all programs and use that as the baseline:

  1. Add min_global_timestamp_offset field to track minimum (global_timestamp - min_global_timestamp)
  2. When displaying progress, use current_offset - min_offset as the time
  3. If current offset is > 60 seconds larger than minimum (indicating a different program with higher PCR base), fall back to showing time relative to the minimum baseline

Test Results

Multi-program DVB teletext sample (dvbt.ts, 6 seconds):

  • Before: 1% | 265:45, 2% | 00:00, 3% | 263:11 ... (jumping wildly)
  • After: 1% | 00:00, 2% | 00:00 ... 87% | 00:05, 100% | 00:00 (stable 0-5 second range)

Single-program DVB subtitle sample:

  • Before and after: 0% | 00:00 ... 100% | 00:34 (no change, still works correctly)

Test plan

  • Build succeeds
  • Multi-program TS file shows reasonable times
  • Single-program TS file timing unaffected
  • Live stream mode updated with same fix

🤖 Generated with Claude Code

@cfsmp3 @claude
fix: Correct progress time display for multi-program TS files
1c781c2 
Multi-program transport stream files can have different PCR (Program
Clock Reference) bases for each program. For example, one program might
have timestamps starting at 23 hours, another at 25 hours. This caused
the progress time display to show wildly incorrect values like "265:45"
for a 6-second file.

The fix tracks the minimum timestamp offset seen across all programs and
uses that as the baseline. When timestamps from programs with higher PCR
bases are encountered (offset > 60 seconds from minimum), the display
falls back to showing time relative to the minimum baseline.

Changes:
- Add min_global_timestamp_offset field to lib_ccx_ctx to track the
  minimum PCR-based offset seen
- Update progress display logic in general_loop.c to normalize times
  relative to the minimum offset
- Apply same fix to both live stream and file processing modes

Test results with multi-program DVB teletext sample (dvbt.ts):
- Before: 1% | 265:45, 2% | 00:00, 3% | 263:11, ... (jumping wildly)
- After:  1% | 00:00, 2% | 00:00, ... 87% | 00:05, 100% | 00:00 (stable)

Single-program files continue to work correctly.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
cfsmp3 added a commit to CCExtractor/sample-platform that referenced this pull request Jan 11, 2026
@cfsmp3 @claude
fix: Include target_url in GitHub status for timed-out tests
2c021ae 
When a test times out due to exceeding the maximum runtime limit, the
GitHub status was set to ERROR but without a target_url. This made it
impossible for users to click through to see what happened - they would
just see "ERROR" with no link.

Root cause: In delete_expired_instances(), update_status_on_github() was
called without the target_url parameter, which resulted in GitHub
displaying a null/empty URL.

Fix: Build the target_url (using url_for with fallback for non-request
context) and pass it to update_status_on_github() so users can navigate
to the test page to see results even when a test times out.

Discovered while investigating why CCExtractor/ccextractor#2007 Linux
test showed ERROR on GitHub with no clickable link. Test #7736 had run
for ~4 hours, executed 116 regression tests (105 failed), but was
canceled due to time limit. The test page existed and showed results,
but GitHub had no link to it.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@cfsmp3 cfsmp3 mentioned this pull request Jan 11, 2026
Merged
4 tasks
canihavesomecoffee pushed a commit to CCExtractor/sample-platform that referenced this pull request Jan 11, 2026
@cfsmp3 @claude @canihavesomecoffee
fix: Include target_url in GitHub status for timed-out tests
4f550bb 
When a test times out due to exceeding the maximum runtime limit, the
GitHub status was set to ERROR but without a target_url. This made it
impossible for users to click through to see what happened - they would
just see "ERROR" with no link.

Root cause: In delete_expired_instances(), update_status_on_github() was
called without the target_url parameter, which resulted in GitHub
displaying a null/empty URL.

Fix: Build the target_url (using url_for with fallback for non-request
context) and pass it to update_status_on_github() so users can navigate
to the test page to see results even when a test times out.

Discovered while investigating why CCExtractor/ccextractor#2007 Linux
test showed ERROR on GitHub with no clickable link. Test #7736 had run
for ~4 hours, executed 116 regression tests (105 failed), but was
canceled due to time limit. The test page existed and showed results,
but GitHub had no link to it.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@cfsmp3 cfsmp3 closed this Jan 11, 2026
@cfsmp3 cfsmp3 reopened this Jan 11, 2026
@ccextractor-bot
Copy link
Collaborator

ccextractor-bot commented Jan 11, 2026

CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 0228fbc...:
Report Name Tests Passed
Broken 13/13
CEA-708 14/14
DVB 6/7
DVD 3/3
DVR-MS 2/2
General 27/27
Hardsubx 1/1
Hauppage 3/3
MP4 3/3
NoCC 10/10
Options 85/86
Teletext 21/21
WTV 13/13
XDS 34/34

Your PR breaks these cases:

Congratulations: Merging this PR would fix the following tests:

  • ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65..., Last passed: Never
  • ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b..., 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

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.

@ccextractor-bot
Copy link
Collaborator

ccextractor-bot commented Jan 11, 2026

CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 0228fbc...:
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 85/86
Teletext 21/21
WTV 13/13
XDS 34/34

Your PR breaks these cases:

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

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 cfsmp3 merged commit 2028754 into master Jan 11, 2026
58 of 60 checks passed
@cfsmp3 cfsmp3 deleted the fix/multi-program-ts-progress-time branch January 11, 2026 19:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@cfsmp3 @ccextractor-bot