[PR #1811] fix(rust): correctly count and store multiple input files #2558

New Issue

claunia · 2026-01-29T17:22:46Z

claunia commented

2026-01-29 17:22:46 +00:00

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

State: closed
Merged: Yes

Summary

Fix bug where num_input_files was always set to 1 regardless of how many input files were provided
Fix bug where input files were stored at wrong indices (0, 10, 20... instead of 0, 1, 2...)

Root Cause

Two bugs in the Rust argument parsing code prevented multi-file processing from working:

Bug 1: Incorrect iteration in `common.rs:216`

// BUG: .iter() on Option<Vec<String>> yields 0 or 1 items (the Vec itself), not Vec contents
options.inputfile.iter().filter(|s| !s.is_empty()).count()

// FIX: Iterate over the Vec contents
options.inputfile.as_ref().unwrap().iter().filter(|s| !s.is_empty()).count()

Bug 2: Wrong indexing in `parser.rs:append_file_to_queue()`

The function used inputfile.len() as the index for new files, but after resize(10, String::new()), the length becomes 10 even with only 1 file. This caused the second file to go to index 10, third to index 20, etc.

Fixed by simply using push() instead of manual index calculation.

Test plan

Build ccextractor with fixes
Test with multiple input files: ccextractor file1.mpg file2.mpg file3.mpg -o output.srt
Verify all files are opened (check for "Opening file:" messages)
Verify no crash occurs
Run cargo clippy - no warnings on changed files

Fixes #1810

🤖 Generated with Claude Code

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/1811 **State:** closed **Merged:** Yes --- ## Summary - Fix bug where `num_input_files` was always set to 1 regardless of how many input files were provided - Fix bug where input files were stored at wrong indices (0, 10, 20... instead of 0, 1, 2...) ## Root Cause Two bugs in the Rust argument parsing code prevented multi-file processing from working: ### Bug 1: Incorrect iteration in `common.rs:216` ```rust // BUG: .iter() on Option<Vec<String>> yields 0 or 1 items (the Vec itself), not Vec contents options.inputfile.iter().filter(|s| !s.is_empty()).count() // FIX: Iterate over the Vec contents options.inputfile.as_ref().unwrap().iter().filter(|s| !s.is_empty()).count() ``` ### Bug 2: Wrong indexing in `parser.rs:append_file_to_queue()` The function used `inputfile.len()` as the index for new files, but after `resize(10, String::new())`, the length becomes 10 even with only 1 file. This caused the second file to go to index 10, third to index 20, etc. Fixed by simply using `push()` instead of manual index calculation. ## Test plan - [x] Build ccextractor with fixes - [x] Test with multiple input files: `ccextractor file1.mpg file2.mpg file3.mpg -o output.srt` - [x] Verify all files are opened (check for "Opening file:" messages) - [x] Verify no crash occurs - [x] Run cargo clippy - no warnings on changed files Fixes #1810 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claunia added the pull-request label 2026-01-29 17:22:46 +00:00

claunia closed this issue

2026-01-29 17:22:46 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#2558

[PR #1811] fix(rust): correctly count and store multiple input files #2558

Summary

Root Cause

Bug 1: Incorrect iteration in common.rs:216

Bug 2: Wrong indexing in parser.rs:append_file_to_queue()

Test plan

Bug 1: Incorrect iteration in `common.rs:216`

Bug 2: Wrong indexing in `parser.rs:append_file_to_queue()`