[mythtv-users] Yeechang: Ticket #1660

[Chris Pinkham]

* On Thu Apr 05, 2007 at 08:45:32AM -0400, Steven Adeff wrote:
> But to me (silly little electric power engineer...) it would seem that
> if the limiting factor to getting data from the firewire device (in
> our case the cablebox) so as to not loose any data is the size of the
> buffer on the firewire card/chip/bus(?), then wouldn't placing a
> buffer on the collection side of things so that the limited hardware
> buffer does not overrun and then let processing catch up after it
> occasionally gets held up be the best option?

That's what I'm advocating.  I know virtually zilch about the firewire
stuff, but it appears that we register a listener and the driver gives
data to us by calling FirewireRecorder::AddData().  If our AddData
can't keep up with how fast the driver needs to send us data then
we're out of luck.  AddData() needs to handle data collection as fast
as possible and then let the consumer of that data handle the data at
it's own pace that may not be non-real-time but is still fast enough
to keep up.

> Another question, what is causing the processing to cause occasional
> hold ups? Is it a processor speed thing, does it have to do with SQL?

The DB updates were the main thing, but who is to say there won't be
something else down the line or couldn't be something else now.
Buffering the data at the source (ie, AddData()) would solve the issue
no matter where a temporary delay occurs.

--
Chris