[mythtvnz] Pixellation Every ~ 20 minutes

[Stephen Worthington]

On Tue, 16 Oct 2012 22:42:08 +1300, you wrote:

>On Tue, Oct 16, 2012 at 8:44 PM, Stephen Worthington <
>stephen_agent at jsw.gen.nz> wrote:
>
>> In recording DVB-T, there is no encoding being done - the packets for
>> that program's streams are just selected out of the full set of
>> packets for the multiplex, and then they are written directly to disk.
>> So the corruption would have to already be in the packets being read
>> from the tuner (ie a reception problem), or in the software selecting
>> and buffering the packets to write them to disk.  An overflow in the
>> buffers waiting to be written is the most likely idea.
>
>
>It does sound that way. But 20 minutes is quite a lot of buffering - it
>must be a buffer in the hundreds of MB which really can only be the
>filesystem buffer cache, right? What's the bit rate for SD programs on
>Freeview HD btw?

The bit rate varies between channels, and between programmes.  And
H.264 is a variable bit rate encoding normally.  So the same amount of
data being recorded before the problem hits would mean that the time
from the start of the program that it hit at would also vary a bit.

There is no way that you have 20 minutes of buffering!  So the bug is
not going to be hitting the first time the end of the buffers is
reached.  Buffering bugs often occur when the buffer wraps around,
either at the end of a buffer, or when the last available buffer has
been used and the first one needs to be re-used.  But if they happen
every time you reach the end of the buffers, they would never pass
even the most cursory testing regime.  So what you get are bugs that
hit only when two things that are happening at different rates happen
at the same time.  Like an interference pattern between two different
signals.  So it may happen only every umpteenth wraparound.  Or it may
be more complex and the first hit happens in the 20 minute region, but
the next is a different time away.  One common problem is when a
interrupt occurs at the same time as something using the buffer at the
same time as the interrupt routine, and the locking is not quite right
between them.  Interrupts are often thought of as happening randomly,
but that is far from true and they have patterns, frequencies, and
often happen at times that are offsets from when something in the main
code set up an activity.  You can get situations where there is a bug
in the interrupt code locking, but it has no effect until some other
interrupt happens at the same time and delays response to the buggy
interrupt.  That can cause all sorts of interesting patterns in when
it happens.

It would be very interesting to compare the file sizes of two
recordings of the same programme done with the same settings, one with
your bug happening, and one without.  If they are both started and
finished at the same time, they should be exactly the same length.  If
your file is significantly shorter, then it is likely that you are
losing data before it gets to the disk.  I am not sure if they would
need to be recorded from the same transmitter - probably not.

>But that
>> should affect all tuners, or all tuners writing to that disk, not just
>> your particular model of tuner.
>>
>
>If it were an internal buffer on the card (or a firmware bug) it could be
>specific to a particular model. I'd try recording something directly from
>the card (i.e. bypass Myth) to rule that out.

That would certainly be a useful test.

>Cheers,
>Steve