[BUG]: Last EIT section never parsed — EPG_free() discards pending epg_buffers without flushing
Maintainers usually reply within 1 day
Nobody has claimed this yet.
- #2166 by @Varadraj75 — closed without merging
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 55/100
Research direction
Read src/lib_ccx/ts_tables_epg.c, starting with EPG_free(), parse_EPG_packet(), and EPG_parse_table(). Trace how pending epg_buffers entries are represented and inspect the related XXX hack in EPG_DVB_decode_EIT(). Done means the final accumulated EIT section is processed before buffers are released without introducing the reported segfault.
Written by the indexing model from the issue text.
Description
Summary
In src/lib_ccx/ts_tables_epg.c, the last EIT section in any stream is silently
discarded because EPG_free() frees epg_buffers without first flushing
accumulated data.
Root Cause
parse_EPG_packet() accumulates TS packets into epg_buffers[] and only calls
EPG_parse_table() when a new section starts (payload_start_indicator=1).
This means the last accumulated section is never parsed — there is no
following packet to trigger the flush.
EPG_free() then frees the buffers without processing them:
void EPG_free(struct lib_ccx_ctx *ctx)
{
// ... output logic ...
free(ctx->epg_buffers); // ← pending data discarded here!
free(ctx->eit_programs);
}
Impact
- The last EIT table section in every stream is lost
- For short streams or streams with few EIT sections, this can mean entire
programs are missing from XMLTV output - There is a related
XXX hackcomment inEPG_DVB_decode_EIT()at line 1420
that was added to prevent a segfault caused by this same issue
Fix
In EPG_free(), before freeing, iterate over all epg_buffers slots and
flush any with ccounter > 0:
// Flush any pending EIT sections before freeing
for (int i = 0; i <= 0xfff; i++) {
if (ctx->epg_buffers[i].buffer != NULL && ctx->epg_buffers[i].ccounter > 0) {
EPG_parse_table(ctx, ctx->epg_buffers[i].buffer,
ctx->epg_buffers[i].buffer_length);
free(ctx->epg_buffers[i].buffer);
ctx->epg_buffers[i].buffer = NULL;
}
}
- Dominant language
- C
- Stars
- 901
- Forks
- 592
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CCExtractor/ccextractor
-
[BUG] Legacy options -608, -708, -90090, -UCLA, -CC2, -LF, -DF, -parsepat, -parsepmt still rejected after #1856Possibly taken @Deepak-negi11 claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
CCExtractor/ccextractor#2367 ·
Maintainers usually reply within 1 day
-
[BUG] Memory leak in free_sub_track(): blockaddition and message buffer never freed for WebVTT tracksPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 86/100
CCExtractor/ccextractor#2247 ·
Maintainers usually reply within 1 day
-
`--out=mcc`: CDP cc_count field overflows above 31 triplets; uint8 `data_size` corrupts lengths and over-reads at higher countsPossibly taken @kaihere14 claimed this 8 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 72/100
CCExtractor/ccextractor#2365 · 1 comment ·
Maintainers usually reply within 1 day
-
[BUG] MAX_CC_COUNT = 31 in ccxr_process_cc_data silently discards CEA-708 data on H.264 frames with multiple SEI messagesPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 68/100
CCExtractor/ccextractor#2358 · 1 comment ·
Maintainers usually reply within 1 day
-
--tpages-all extracts less than --tpagePossibly taken @SajalDevX claimed this 16 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 65/100
CCExtractor/ccextractor#2355 ·
Maintainers usually reply within 1 day
All issues in CCExtractor/ccextractor
Similar issues
-
backlog
Difficulty 1/5 Under an hour Newbie friendliness 82/100
EchoTools/nevr-runtime#454 ·
Maintainers usually reply within 1 day
-
initramfs: -type f (#18686) skips the libcurl.so.4 symlink, libcurl no longer copied into initramfsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
common/json_parse: json_to_bitcoin_amount fails to detect overflow and accepts negative/empty inputsPossibly taken @bhuvan-somisetty claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
ElementsProject/lightning#9617 ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
zephyrproject-rtos/zephyr#121795 ·
Maintainers usually reply within 2 days