[mythtv-users] Yeechang: Ticket #1660

Chris Pinkham cpinkham at bc2va.org
Tue Apr 3 04:40:53 UTC 2007


* On Mon Apr 02, 2007 at 08:15:32PM -0700, Yeechang Lee wrote:
> Steven Adeff <adeffs.mythtv at gmail.com> says:
> > you mention it didn't have any affect on your ATSC recordings, does
> > this still hold true?
> 
> Note that I was referring to only using the patch that's now part of
> trun and 0.20-fixes, as opposed to ajlill's full-blown
> asynchronous-database work, which still hasn't been integrated yet.

And probably will never be...  See my comment in the ticket.

To make sure I'm getting this straight, when you say your ATSC recordings
were seemingly unaffected with current -fixes, do you mean that the only
thing broken still is firewire?  I think the firewire issue needs to be
resolved by putting the data collection in a different thread than the
data consumption.

We have this call tree:

FirewireRecorder::AddData(const unsigned char *data, uint len)
 -> FirewireRecorder::ProcessTSPacket()
  -> DTVRecorder::FindMPEG2Keyframes()
   -> DTVRecorder::HandleKeyframe()
    -> DTVRecorder::SavePositionMap()

When SavePositionMap takes too long to run because the DB is slow,
then the firewire reader misses data.  We need to buffer the data inside
FirewireRecorder::AddData() and consume it in another thread.  I think I
remember Daniel mentioning something about using a read buffer in here
as we already do in some of the other recorders.

Branching off the SavePositionMap() stuff into another thread is only
putting a band-aid on the situation, anything else along the line could
cause that reader to hang up too long and cause dropped data.

Now, all these assumptions/ideas are based on 5 minutes of looking at the
firewire recorder code which makes it about 6 minutes total that I've looked
at that code ever, so I may be wrong, but it seems to make sense based on
my knowledge of the other recorders.

--
Chris


More information about the mythtv-users mailing list