Private:mtv issues

MPE, and MPE-FEC sections are not being picked up by dvbSAM

Current Status:

The Bug:

When the program is run using the STAND algorithm and the TS file is generated, dvbSAM has determined that there are entire MPE and/or MPE-FEC sections missing inside some bursts. (Maybe some are half missing as well, but I have not verified this claim)
There does not seem to be a pattern in determining which burst will be missing sections. Some bursts will be 100% complete whereas some bursts will be missing at least one section of data.
The MPE and/or MPE-FEC sections missing also seem to be randomly determined.
Unfortunately a different TS file gets generated even if you run the program with the same configurations. This means that dvbSAM shows different #of packets per burst, different #of bytes corrected by MPE-FEC, etc. I produced at least 5 different TS files using the same configurations, none of which contained identical burst sequences.

Perfect burst: Problematic burst: Section preceding missing section:

Section proceeding missing section:

Theory of why this is happening:

There is some semantic error in the code, possibly very small.
I believe that dvbSAM is throwing out some TS packets which happen to include the MPE/MPE-FEC header information which causes the entire section of data to be discarded.
The fact that there are some bursts which are perfect suggests that all the MPE and MPE-FEC sections are being generated correctly. And this in turn would also suggest that packing MPE, MPE-FEC, and TS packets are done correctly.

Steps Taken:

EDIT:*Analyzed Burst::enc_ts(), all ts sections DOES NOT seem logically generated

Created file containing hex dump of the burst being passed to Transmitter using Burst::dump_ts(). I viewed the TS file using dvbSAM to pick out missing sections in the burst. Then I looked into the hex dump for the TS packets containing the MPE/MPE-FEC section preceding the missing section, the missing section, and the section proceeding the missing section. All sections were found in the hex dump. The TS header seemed incorrect; some had 4 bytes, but should have 5.