<div class="gmail_quote">On Sun, Sep 4, 2011 at 2:58 PM, Brian J. Murrell <span dir="ltr"><<a href="mailto:brian@interlinx.bc.ca">brian@interlinx.bc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11-09-03 03:31 PM, Raymond Wagner wrote:<br>
> In order to ensure the frontend does<br>
> not get starved of data, it enforces a couple second lag.<br>
<br>
</div>Yeah, in the recent discussion we had about this I proposed that the<br>
frontend should not have to read the stream slightly behind the writer,<br>
therefore imposing this lag. But as was pointed out, the VFS probably<br>
ensures that the read least doesn't physically go to disk, so that's<br>
probably a moot issue anyway.<br> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
But there is this lag introduced to ensure the frontend doesn't starved.<br>
But why should it ever be, as long as it is not playing back faster<br>
than the backend is writing? The only way a starvation of any kind<br>
could be effected is if the frontend is trying to read bigger chunks<br>
than the delay between the frontend and backend allows to be written.<br>
Of course, fewer bigger reads are better than lots of smaller ones, but<br>
when the data is in the cache already, perhaps the small read penalty is<br>
minimized and therefor also the "lag delay" can be minimized.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Sorry, but faster LiveTV and channel changing speed likely aren't the highest on the priority list. They "work" :)</div></div>