[mythtv-users] recording problems with recent 'fixes' build

[Paul Harrison]

Udo van den Heuvel wrote:
> Paul Harrison wrote:
>   
>> Udo van den Heuvel wrote:
>>     
>>> What can I do to find the cause?
>>>       
>> What svn revision exactly?
>>     
>
> 19356 gave me trouble.
> That trouble isn't in 18670.
>
>   
>> There was a bug in r19342  that IIRC was causing an infinate loop that 
>> sounds something like the problem you are having. It was fixed by r19358 
>> late on the 13th Dec.
>>     
>
> Interestingly I built 19356 on the 13th (2008-12-13 14:48 CET).
> So I might try a fresh build you mean?
>
> Thanks for the info.
> Will have a look at 19358.
>
> Udo
>   
Yes  you've just been unlucky and grabbed a revision  just before the 
fix went in. Just do an svn up to get the latest revision an all will be 
well again :-)

As you can see the fix only went in at 2008-12-13 20:54:37 +0000

------------------------------------------------------------------------
r19342 | jarod | 2008-12-12 03:13:31 +0000 (Fri, 12 Dec 2008) | 16 lines

mpeg: don't try to overwrite any of the incoming packet buffer

In the event the mpeg stream parser fails to process a given packet,
it was overwriting the current packet's sync byte w/a non-sync-byte
value, to signal that we should resync the stream. This works with
many buffers, but not those produced by the new(er) Linux FireWire?
stack, as the incoming buffer is write-only for the controller.
Trying to overwrite the buffer results in a segfault. This works
around the issue by simply adding a resync flag, and now I've got
my cable box working pretty darned reliably (about 20 consecutive
livetv start/stops, with multiple channel changes, and I haven't
hit the segfault, which used to trigger roughly 60% of the time).

Backport of [19341] from trunk.

-----------------------------------------------------------------------
r19358 | awithers | 2008-12-13 20:54:37 +0000 (Sat, 13 Dec 2008) | 4 lines

Merges [19357] from trunk.

  Avoids infinite loop possibility introduced in [19342].

Paul H.