[mythtv-users] PVR250 + TVWonder = jerky

[Isaac Richards]

On Thursday 05 June 2003 04:13 am, michael at optusnet.com.au wrote:
> Isaac Richards <ijr at po.cwru.edu> writes:
> > On Wednesday 04 June 2003 10:05 pm, michael at optusnet.com.au wrote:
> > > I didn't find this problem in my testing. I could stream 20
> > > megabytes/sec out of the backend with a hacked up requestor. Why do
> > > you think this is a problem? (This is easy to test: Write a few lines
> > > of perl to do a connect to the backend, and stuff request blocks
> > > down as fast as you can, just counting and dumping the data the comes
> > > back).
> >
> > That's not really a realistic test, since the perl client isn't using the
> > QSocket stuff.
>
> Quote: "Nope.  The issue is that due to the scheduler and the way all
> backend requests are synced and due to them using the Qt event loop
> and everything, there's a limited number of requests you can make of
> the backend in any given time period."
>
> What does the perl client not using QSocket stuff have to do with
> the backend performance??

Who said the issue was with the backend?  If the issue is in the way 
communications work between the two, not duplicating one end of the 
conversation doesn't demonstrate it, of course.

The 'slow seeking' issue you had thought was the ringbuffer was exactly this 
issue -- it was doing a fairly large number of backend queries in a tight 
loop, and that was taking a set amount of time.  Changing the protocol so 
that it could make the same number of requests in a single query fixed 
things.

> > Send in a diff without all the extraneous changes you had in the original
> > one, then, and I'll see about getting it committed.
>
> The 'extraneous changes' shrank the code size by nearly 200 lines as I
> very vaguely recall.
>
> Am I being stupid, and missing some reason that you're keen on having
> code duplicated in so many places?

Both Matt and I told you last time that making it completely non-obvious which 
mode the RingBuffer class was in (ringbuffer or normal file) was not a good 
thing.  Splitting the functionality into a pair of classes would most likely 
be acceptible, though.

Also, adding in comments like:

+// We're creating a new circular buffer file, as used by LiveTV and
+// similar things. There's a long of assumed behaviour here.
+//
+// In particular, it seems that this means we're ALWAYS writable,
+// and that the file size can't get more than 'size'.
+// I don't know what 'smudge' is for.

Well, for one, I really don't like applying patches that I have to edit while 
applying them, and two, you probably shouldn't be submitting 'cleanup' 
patches without understanding what the original code does.  Finally, I really 
prefer that cosmetic improvements be submitted for consideration separately 
from functional improvements.

Isaac