Andreas Pickart schrieb:
> VDR (1.6.0-2) crashed after stuffing the syslog with:
> vdr:  ERROR: possible result buffer overflow, dropped 13 out of
> 13 byte
> vdr:  ERROR: possible result buffer overflow, dropped 2048 out of
> 2048 byte
> A backtrace shows that the function cTS2PES::write_ipack (initially
> called from cTS2PES::instant_repack with Count=184) kept calling itself
> (from then on with Count=180 and the same "Data" pointer all the time).
> The variable "bite" was 4 on the first call and then 0 on all succeeding
> It was a video pid being extracted, so the cVideoRepacker got called,
> and I suspect its "breakAt" return value lead to the "// should never
> happen" code that set "bite" to 0.
> Some state information from the cTS2PES instance:
> pid=1023 size=2052 found=2200 count=2052
> cid=224 rewriteCid=224 subStreamId=0
> plength=4194234 plen=98 plen=124 flag1=flag2=0 hlength=0 mpeg=0
> check=0 mpeg1_required=mpeg1_stuffing=0
> tsErrors=2020124 ccErrors=697951
> The high error counts obviously show that the received data (from DVB-S)
> was somehow defective (There were many "PES packet shortened" errors
> earlier), but ideally VDR shouldn't crash even when the data is broken...
> Can anyone please fix this issue?
Is there a regular chance for you to reproduce this issue?
I could send you a code fragment then which would store a
reasonably sized fragment of the TS stream which would help me
very much in solving this issue.
Dipl.-Inform. (FH) Reinhard Nissl
vdr mailing list