[mythtv-users] random livetv stalls

[Kevin Johnson]

>
> > I do use nfs on the backend.  But mythtv does not use that directory at
> all.
> > All my frontends can access that shared nfs directory on the backend.
> > However I only use nfs to share random files and other minor things.
> > Could the nfs mounts still be causing this?
>
> if the file is available locally, the frontend will access it directly
> instead of streaming it from the backend.
>
> by locally, it means that there's a direct path to the file, be it via
> a locally mounted file system or networked (NFS, SMB you name it)
>
> example:
> the backend store the recordings to:
> /data/recordings/recording1.mpg
>
> the frontend has mounted /data/recording via NFS
> the frontend sees that the file /data/recordings/recording1.mpg exists
> it will read directly the file.
> So here, it goes via NFS and will *not* stream it from the backend.
>
> I've personally experienced issue with NFS, not so much the speed of
> transfer, but the lag between the time one client write to the file
> and the time another client sees the new size.
>
> I was mounting NFS with the option: rsize=8192,wsize=8192,timeo=14,intr
>
> Simply because that's what I had been using it for years and many
> tutorial give those options.
> intr is a deprecated option, and does nothing with kernel >= 2.6.26
>
> removing rsize=8192,wsize=8192 fixed the issue for me.
> So now I only have timeo=14 as nfs mounting option. That resolved the
> hang issue I was having in livetv...
>
> Having said that, as a trial I would unmount the NFS filesystem. Let
> the frontend access the recording by streaming it from the backend.
>
> And see how it goes.
>
>
Unless I am not understanding how mythtv works, my mythtv setup does not
use nfs.
This is my exports config.
/D2/share *(rw,async,no_root_squash,no_subtree_check)
No other entries are in there.

Mythtv does not store any recordings in the /D2/share directory.
So that should eliminate nfs as a issue right?  Or do I not understand
correctly?

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140206/1fa6f20d/attachment.html>