[PR #1880] [FIX]: Prevent CEA-708 decoder panic with -stdout on Windows #2669

New Issue

claunia · 2026-01-29T17:23:20Z

claunia commented

2026-01-29 17:23:20 +00:00

Original Pull Request: https://github.com/CCExtractor/ccextractor/pull/1880

State: closed
Merged: No

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.

Fix #1478: Prevent CEA-708 service decoder panic when using `-stdout` on Windows

Issue Summary

Issue #1478 reports a panic in CCExtractor 0.94 when using -stdout with HDHomeRun-recorded .ts files on Windows:

Original crash reported:

thread '' panicked at 'index out of bounds: the len is 1 but the index is 1', 
src\decoder\service_decoder.rs:275:25

Reproduction

I reproduced a similar panic on Windows 0.94 portable build using -stdoutand sample file from #1478:

My reproduction:

PS> $env:RUST_BACKTRACE=1
PS> .\ccextractorwinfull.exe -stdout cctest1.ts > C:\Users\Public\ccStdOut.txt

CCExtractor 0.94, Carlos Fernandez Sanz, Volker Quetschke.
Teletext decoder: Petr Kutalek
...
Opening file: cctest1.ts
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "Filename missing"', 
src\decoder\service_decoder.rs:897:43

Root Cause Analysis

Although the panics are reported at different line numbers across builds, they stem from the same underlying issue in the CEA-708 service decoder.
On Windows, when running with -stdout, transcript output is effectively disabled or not fully initialized (no output filename, different writer setup). However, the decoder still executes code paths that assume a fully configured transcript writer.
This results in panics in different places depending on build and execution path:
Failed Writer::new() being unconditionally used (e.g. “Filename missing”)
Accessing a non-existent writer context (index out of bounds)
While the exact panic location varies, both failures indicate that writer-related state is accessed when transcript output is not valid.
This fix adds an explicit check for transcript_settings and exits early when transcript output is disabled, preventing invalid writer usage. Behavior when transcript output is enabled remains unchanged.

Changes Made

Modified src/rust/src/decoder/service_decoder.rs to add defensive checks in two methods:

1. `screen_print()` method:

Check if transcript_settings exists before attempting Writer creation
Return early if transcript output is disabled (instead of panicking)
Remove .unwrap() call that caused the panic

2. `flush()` method:

Add same defensive check for transcript_settings
Return early if transcript output is not configured
Prevent similar panic scenarios during cleanup

Testing

Cross-platform tested:

macOS (M4): Successfully built and tested with the sample file provided in the issue; -stdout generates valid SRT output with no regressions observed.
Linux (Ubuntu 22.04): Built and tested using the same approach as macOS; output is correct and unchanged.

Request for Windows testing

I was unable to test whether this fix resolves the crash on Windows, as I currently don't have access to a Windows build environment. Testing on Linux and macOS shows no regressions, but Windows-specific validation via community testing would be valuable.
If anyone with a Windows machine can test with the sample file from #1478, that would be greatly appreciated!

Why This Fix Should Work

Even though the panic line numbers differ between the original report (275) and my reproduction (897), this fix addresses what appears to be the root cause based on available evidence:

The Fix Strategy:

Before any Writer operations, check if transcript output is properly configured
If not configured, skip transcript output gracefully instead of attempting to use an uninitialized Writer
This should prevent panics at any point where Writer is accessed (creation, usage, or cleanup)

Even if this doesn't address the exact root cause of the line 275 panic (due to build differences or additional factors), the fix provides important safety guarantees:

Prevents panics from null/missing transcript_settings
Fails gracefully instead of crashing

At minimum, this fix makes the codebase more robust against Writer initialization issues on Windows.

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/1880 **State:** closed **Merged:** No --- **In raising this pull request, I confirm the following (please check boxes):** - [X] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [X] I have checked that another pull request for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. - [x] **I have mentioned this change in the [changelog](https://github.com/CCExtractor/ccextractor/blob/master/docs/CHANGES.TXT).** **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. - [X] I am an active contributor to CCExtractor. --- ## Fix #1478: Prevent CEA-708 service decoder panic when using `-stdout` on Windows ## Issue Summary Issue #1478 reports a panic in CCExtractor 0.94 when using `-stdout` with HDHomeRun-recorded `.ts` files on Windows: **Original crash reported:** ``` thread '' panicked at 'index out of bounds: the len is 1 but the index is 1', src\decoder\service_decoder.rs:275:25 ``` ## Reproduction I reproduced a similar panic on Windows 0.94 portable build using `-stdout`and [sample file from #1478](https://1drv.ms/u/s!Ai_hpL0GElr6o-huZrnjSdk7hmW8Wg?e=Sv0PD6): **My reproduction:** ```powershell PS> $env:RUST_BACKTRACE=1 PS> .\ccextractorwinfull.exe -stdout cctest1.ts > C:\Users\Public\ccStdOut.txt CCExtractor 0.94, Carlos Fernandez Sanz, Volker Quetschke. Teletext decoder: Petr Kutalek ... Opening file: cctest1.ts thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "Filename missing"', src\decoder\service_decoder.rs:897:43 ``` ## Root Cause Analysis - Although the panics are reported at different line numbers across builds, they stem from the same underlying issue in the CEA-708 service decoder. - On Windows, when running with `-stdout`, transcript output is effectively disabled or not fully initialized (no output filename, different writer setup). However, the decoder still executes code paths that assume a fully configured transcript writer. - This results in panics in different places depending on build and execution path: - Failed `Writer::new()` being unconditionally used (e.g. “Filename missing”) - Accessing a non-existent writer context (index out of bounds) - While the exact panic location varies, both failures indicate that writer-related state is accessed when transcript output is not valid. - This fix adds an explicit check for `transcript_settings` and exits early when transcript output is disabled, preventing invalid writer usage. Behavior when transcript output is enabled remains unchanged. ## Changes Made Modified `src/rust/src/decoder/service_decoder.rs` to add defensive checks in two methods: ### 1. `screen_print()` method: - Check if `transcript_settings` exists before attempting Writer creation - Return early if transcript output is disabled (instead of panicking) - Remove `.unwrap()` call that caused the panic ### 2. `flush()` method: - Add same defensive check for `transcript_settings` - Return early if transcript output is not configured - Prevent similar panic scenarios during cleanup ## Testing **Cross-platform tested:** - **macOS (M4)**: Successfully built and tested with the sample file provided in the issue; -stdout generates valid SRT output with no regressions observed. - **Linux (Ubuntu 22.04)**: Built and tested using the same approach as macOS; output is correct and unchanged. ## **Request for Windows testing** - I was unable to test whether this fix resolves the crash on Windows, as I currently don't have access to a Windows build environment. Testing on Linux and macOS shows no regressions, but Windows-specific validation via community testing would be valuable. - If anyone with a Windows machine can test with the [sample file from #1478](https://1drv.ms/u/s!Ai_hpL0GElr6o-huZrnjSdk7hmW8Wg?e=Sv0PD6), that would be greatly appreciated! ## Why This Fix Should Work Even though the panic line numbers differ between the original report (275) and my reproduction (897), this fix addresses what appears to be the root cause based on available evidence: The Fix Strategy: - Before any Writer operations, check if transcript output is properly configured - If not configured, skip transcript output gracefully instead of attempting to use an uninitialized Writer - This should prevent panics at any point where Writer is accessed (creation, usage, or cleanup) Even if this doesn't address the exact root cause of the line 275 panic (due to build differences or additional factors), the fix provides important safety guarantees: - Prevents panics from null/missing transcript_settings - Fails gracefully instead of crashing At minimum, this fix makes the codebase more robust against Writer initialization issues on Windows.

claunia added the pull-request label 2026-01-29 17:23:20 +00:00

claunia closed this issue

2026-01-29 17:23:20 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#2669

[PR #1880] [FIX]: Prevent CEA-708 decoder panic with -stdout on Windows #2669

Fix #1478: Prevent CEA-708 service decoder panic when using -stdout on Windows