[mythtv] [mythtv-commits] Ticket #2708: patch: Allow remote FE/BE to prefer to use the myth protocol

[Bruce Markey]

Chris Pinkham wrote:
> * On Tue Nov 21, 2006 at 04:35:47PM -0500, Daniel Kristjansson wrote:
>> This is almost certainly because we require a larger buffer when
>> streaming, and for some reason your network needs the larger buffer.
>> It would be easy to add a "Do Extra Buffering" checkbox and add
>> the needed change in the RingBuffer initialization parameters.
> 
> That's what I was thinking as well and figured that would have helped out
> the few times I've seen the issue with my NFS-mounted recording directories.
> 
> I don't mind adding something to force using the myth:// protocol even if the
> file might be accessible locally via a remotely mounted directory, but also
> want to try bumping up the buffer sizes on my end to see if it cures the
> issue I was seeing.

Not sure if either of you read these messages correctly
or if I misread your responses:

"FWIW: My in experience streaming works far better...
  ...several posts in the dev & users lists that suggest to
  use streaming rather than nfs mounts."

"I am one that finds streaming via protocol better than
  nfs mount."

They are both saying that serving the files from the backend 
seems to work better than NFS. This is what I'd expect as the
backend method can be application aware of the read ahead and
block size needs. If we can't out-perform NFS then we're doing
something wrong because nothing in NFS was designed with the
needs of mythfrontend specifically in mind =).

Stuttering due to data starvation from the backend was never
a result of the readahead buffer being too small but was always
been because the block size wasn't big enough. The player can
use up data faster than REQUEST_BLOCK will ask for it if the
block size is too small. If the blocks are too big, seeking
like 20X FF is jerky because it is requesting too much data
for each seek position and has to wait for all the unneeded
data to flush.

The block size used to be adjusted based on an estimated bitrate
but that didn't turn out to work so well. What I'm thinking
right now is that maybe the block size should be adjustable
based on the demand for the read ahead buffer. Start small then
grow the block size until the read ahead buffer stays above
some level without having to request too often. This could make
it use small blocks right after seeking then build in size after
a few iteration during continuous playback.

--  bjm