[mythtv-users] long delays responding to keystrokes and ir events

[Josh Mastronarde]

On Sat, Apr 4, 2009 at 11:44 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 04/05/2009 02:02 AM, Josh Mastronarde wrote:
>>
>> Mike and others -- if there are more confirmations that this fix
>> helps, is there a preferred non-rude way to pass a gentle request to
>> an appropriate dev to request is be evaluated to put in the 0.21-fixes
>> branch?
>
> The dev who oversees the libav* stuff already knows about it.  After a very
> quick glance, he said that the patch seems like it wouldn't hurt anything,
> but that it needs cleaning up.  I can't be more specific about what exactly
> needs cleaning (I don't know), but--if nothing else--there were several
> unnecessary whitespace changes that clutter it.

I understand; I wasn't sure exactly how to handle it -- it is strictly
backporting one function from the newest trunk code (I think it's the
same in both the latest mythtv and ffmpeg SVN, but I need to verify
that).  So weirdnesses in the code structure itself are not my fault,
the poor communication trying to explain that is :-)

>
>>  This is my first MythTV patch contribution (albeit more of a
>> cut-and-paste of a procedure from a newer file, although I did the
>> root-cause analysis), and I don't want to go about things the wrong
>> way :-)
>
> And, even better, if the update was simply bringing the
> file/function/whatever up-to-date with upstream source, a /much/ better
> approach may be just to quote the file and (ffmpeg) SVN changeset(s) (or at
> least the minimum SVN revision required) that you're backporting in the
> ticket rather than providing a patch.

Okay, I wasn't sure whether it was better to give pointers like that,
or just provide the actual new code (as a patch).  I'll add this info
to the ticket.

> We try to keep the changes to the libav* code to a minimum to make resyncs
> as painless as possible, so if Janne were able to just include some
> changeset(s) that he will eventually be including, he could easily patch it
> without affecting his ability to resync in the future.

Yes, I wasn't clear enough that this change is already in trunk, so he
only needs to put it in the 0.21-fixes branch; the current and any
future resync with ffmpeg don't need anything special done.

Thanks, Mike, for this input.  Originally, I was just excited to have
figured out how some of it the code works and to have fixed my problem
(it explained a bunch of different weird, but hard to track down,
things I'd been seeing) and was going to leave it at that, since I
wasn't sure if I was the only one with the issue.  But then I realized
the whole point of this type of project is to contribute so others
(who do seem to have the same issue) can benefit, so I figured I'd
delve in and submit it.  I'm a hardware (CPU chipset/integrated
graphics) designer by day, and even 15 years later I get a big charge
the moment we figure out exactly how something's working/broken and
how to elegantly work around it...

Josh