mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-04-25 15:40:02 +00:00
[BUG] Error in switch_to_next_file() #833
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @shri-acha on GitHub (Jun 10, 2025).
I got an error while trying to run an example video i got from on the web.
I'd like some help with solving it.
I've tried to wander around the codebase and found out that below:
line handles the error, and also as the log mentions it, the file being read is probably hasn't been parsed.
Output Images:
Video Used:
Example Video
@tmdeveloper007 commented on GitHub (Oct 28, 2025):
What is the problem ?
The error occurs in the switch_to_next_file() function in file_functions.c:283
when CCExtractor detects that file processing ended prematurely. The condition
that triggers this error is:
if (ctx->inputsize > 0 && ((ctx->demux_ctx->past + bytesinbuffer) <
ctx->inputsize) && is_decoder_processed_enough(ctx) == CCX_FALSE)
This means ---->
total file size
user-defined limits)
@AnujRewar commented on GitHub (Oct 29, 2025):
In my terminal it is showing like this
@DhanushVarma-2 commented on GitHub (Nov 9, 2025):
Hi , I've identified the root cause of this bug and am ready to implement a fix.
Problem Analysis:
The issue is in the is_decoder_processed_enough() function in src/lib_ccx/lib_ccx.c. The current logic is:
if (dec_ctx->processed_enough == CCX_TRUE && ctx->multiprogram == CCX_FALSE)
return CCX_TRUE;
The bug: When multiprogram mode is enabled, this function always returns CCX_FALSE, even when decoders have actually processed enough data.
This causes the condition in switch_to_next_file() to incorrectly trigger the "premature ending" error:
if (ctx->inputsize > 0 &&
((ctx->demux_ctx->past + bytesinbuffer) < ctx->inputsize) &&
is_decoder_processed_enough(ctx) == CCX_FALSE) ← Always true in multiprogram mode
Proposed Fix:
I will modify the is_decoder_processed_enough() function to properly handle multiprogram mode. The function should check if ANY decoder has processed enough data, regardless of multiprogram setting.
I'm working on the implementation now and will submit a PR shortly.