[mythtv-users] LiveTV zapping speed

[Gavin Hurlbut]

On Sun, Sep 4, 2011 at 2:58 PM, Brian J. Murrell <brian at interlinx.bc.ca>wrote:

> On 11-09-03 03:31 PM, Raymond Wagner wrote:
> > In order to ensure the frontend does
> > not get starved of data, it enforces a couple second lag.
>
> Yeah, in the recent discussion we had about this I proposed that the
> frontend should not have to read the stream slightly behind the writer,
> therefore imposing this lag.  But as was pointed out, the VFS probably
> ensures that the read least doesn't physically go to disk, so that's
> probably a moot issue anyway.
>

But there is this lag introduced to ensure the frontend doesn't starved.
>  But why should it ever be, as long as it is not playing back faster
> than the backend is writing?  The only way a starvation of any kind
> could be effected is if the frontend is trying to read bigger chunks
> than the delay between the frontend and backend allows to be written.
> Of course, fewer bigger reads are better than lots of smaller ones, but
> when the data is in the cache already, perhaps the small read penalty is
> minimized and therefor also the "lag delay" can be minimized.


Your whole message seems to be predicated on a false assumption.  The only
way that you can extensively use "the cache" in this way is if your frontend
and backend are the same machine.  MythTV is designed to allow that, but it
also is designed for the backend(s) and frontend(s) to be totally different
machines.  In this eventuality, there's no way to share a cache as the
recording and the playback are separated by a network connection.

Yes, the reads by the frontends are likely reading from cache in the
backend, but you can't synchronize the read/writes in the way that you seem
to be suggesting.  For the frontend playback to work properly, we need to
read large blocks at a time and keep the data streaming, especially with HD
content.  If we went back to smaller reads, we'd have a very difficult time
making things work.  Extensive work has been done to streamline this
already.

Sorry, but faster LiveTV and channel changing speed likely aren't the
highest on the priority list.  They "work" :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20110904/2d053439/attachment.html