Status of Windows tools

[Ken Hancock]

--- In ExtractStream@y..., "Dale E. Reed Jr." <daler@n...> wrote:
> > I'm currently rewriting the input buffering and in the process of 
> 
> Why? I fail to undestand the point of the complex circular buffer
> in ExtractStream and some of the other apps based on it. When I
> ported ConvertStream over to Win32 I yanked all that out. I can
> only assume they were trying to squeeze every little performance
> out of the poor tivo processor, or liked writing complicated 
code. :)

Well, two reasons. (1) the code that was there didn't work and (2) 
circular buffers are not complex. Please repeat after me. "Circular 
buffers are not complex." And people wonder why so many products run 
slow on fast machines...

> My OS has I/O buffering and such built into it. I'm sure I could
> have made ConvertStream faster, but knowing the eventual goal was
> to convert a stream coming over the wire at a limited speed (1MB),
> I didn't want to put any effort into my. My P3 750 was bored as
> it was. :)

I'm sure it wasn't taxing your CPU. That, however, is not the 
point. If everyone writes inefficient code, once you start multiple 
processes, you DO max out your CPU when it could probably be doing 
twice as much work if the code was written properly.

> > debugging it. Extracted a full one hour show last night, but 
it's 
> > obvious it's dropping bytes somewhere, still. Hopefully by next 
> > week...
> 
> Its not that its "dropping" bytes. There is a real shift here in
> how the tivo uses the tystream data and how we are trying to use it.

No, actually it was dropping bytes... I wasn't checking one of the 
read_net calls for EAGAIN return...