[mythtv-users] LiveTV zapping speed

Raymond Wagner raymond at wagnerrp.com
Mon Sep 5 16:22:39 UTC 2011


On 9/5/2011 10:08, Brian J. Murrell wrote:
> On 11-09-04 07:33 PM, Gavin Hurlbut wrote:
>> The only
>> way that you can extensively use "the cache" in this way is if your frontend
>> and backend are the same machine.
> Not at all.  I don't have any BE/FE machines here so why would that
> use-case be my assumption?  You don't have to have a FE on the BE
> machine to take advantage of the cached pages.  Whether the FE is remote
> or local, the caching of pages is still going to have the efficiency of
> not having to read them from disk to deliver them to the client.

There are any number of scenarios involving NFS where this whole thing 
falls through.  Even if you do have your storage on the backend, and are 
streaming the recordings from that specific backend, you will still need 
a modest amount of buffering to ensure smooth playback.  The only time 
this disk cache would be usable to create near bufferless playback is if 
the frontend directly has access to it, requiring the frontend to be on 
the same machine as the backend.
>> but you can't synchronize the read/writes in the way that you seem
>> to be suggesting.
> I'm not suggesting any synchronization.  I'm merely suggesting doing
> smaller reads so that the "lag buffer" need not be so large

Those reads are currently somewhere between 30KB and 120KB, auto-scaling 
based off the speed and reliability of the network.  This could be a 
problem for very low bitrate, digital standard definition content.  
That's only a quarter second of content off an MPEG encoder, and maybe 
2-4 frames of high definition content.  As explained, there are many 
factors that go into the time needed to change channels.  Even if we did 
away with that, there is still the possibility of several seconds worth 
of lag depending on the users hardware configuration.

It all comes down to the fact that it's something that would take a 
considerable amount of time to write, for limited gains depending on 
other hardware issues, in an area of MythTV rarely used by any of the 
active developers.  Would shorter channel changing times be nice? Sure!  
Would changes that improve this behavior be accepted? Assuming it 
doesn't cause problems elsewhere, and is sufficiently robust, probably.  
The problem is just as Gavin stated, low on the priority list.


More information about the mythtv-users mailing list