EIA-708 Closed Caption fails assert. svn 9140 to at least 9144

[teagardn@…]

Since the eia-708 closed captioning code was added, mythfrontend dies with mythfrontend: cc708decoder.cpp:473: void append_cc(CC708Reader*, uint, const unsigned char*, int): Assertion `block_size + cc->buf_size[service_num] < cc->buf_alloc[service_num]' failed.

This did not occur prior to 9140 (since the 708 code didn't exist yet). I don't ever use close captioning, but this assert fails whether it's on or not. The error occurs repeatably in at least one spot in a recording that I had previously been able to watch start to finish.

I get over-the-air broadcast, and my signal was not perfect. After this happened I watched with captions turned on and saw that the caption data had some noise (extra / bad characters) in it.

[anonymous]

gdb log after assert fails

[danielk]

(In [9166]) References #1403. Fixes segfault.

The assert was being triggered because the caption packet buffer grew past a certain point which it shouldn't. This replaces the assert with a realloc.

But this shouldn't be happening in the first place.

teagardn, can you change these three lines in cc708decoder.cpp:

#define DEBUG_CC_SERVICE_2     0
#define DEBUG_CC_RAWPACKET     0
#define DEBUG_CC_SERVICE_BLOCK 0

to

#define DEBUG_CC_SERVICE_2     1
#define DEBUG_CC_RAWPACKET     1
#define DEBUG_CC_SERVICE_BLOCK 1

Then send attach the output from the watcing the same file to about 20 seconds past the point where it crashed before this commit.

[anonymous]

I attached the gdb.txt and myth.log from two runs using svn 9175. The patch in 9166 does not allow the recording to continue playing. However, instead of the assert error now it gives this error: * glibc detected * realloc(): invalid size: 0x000000000149a0f0 * which doesn't appear in the gdb.txt, as far as I can see.

[danielk]

(In [9204]) References #1403. This hopefully fixes the EIA-708 buffer fill problem.

EIA-708 has "delay cancel" and "reset" commands which must be processed out-of-band. But we we're only catching the first of several delay cancels each time through and so letting the buffer fill-up. With this change we find the last of the out-of-band commands. Also if the buffer ever does fill up, we pretend there is a delay cancel at the end of the buffer.

[anonymous]

Your last change seems to have fixed the issue for which this ticket was opened. The recording now plays through without any problem, compiled both with and without debugging enabled. This was all I needed, so thanks! But... I don't know if it's a different problem, or something related to the new changes, but it seems now that the order of characters in the captions are messed up. Example: speaker says this:

I figure at this point I've got nothing to lose.

caption shows this:

 fiI gu aret isth pntoi  
I' gveotot nhi tngo selo.

This is with a 78% signal which on my setup gives smooth audio and video, so I wouldn't think it's a noise problem. Maybe I'm wrong about that.

[danielk]

closing, fixed by [9204].

The unorderded captions are a known problem, see commit [9140] in ticket #1095 for an explanation.