[mythtv-users] How do I get coverart/etc in watch recordings?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Thu Sep 17 02:55:09 UTC 2009


    > Date: Wed, 16 Sep 2009 21:24:16 -0400
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > On 09/16/2009 08:39 PM, Jean-Yves Avenard wrote:
    > > 2009/9/17 Michael T. Dean:
    > >   
    > >> Just in case someone reading this is tempted to try not using actimeo=0, the
    > >> /only/ way that LiveTV with backend LiveTV directories NFS mounted to the
    > >> frontend works in MythTV is with actimeo=0.  And, it's basically a
    > >> requirement for Myth anywhere one system is writing things and another
    > >> tries/needs to see them immediately.

It's a little disconcerting that Myth can't tolerate being even 1
second behind on NFS attributes, as actimeo=1 should ensure.  Would
this necessarily mean that someone is within 1 second of realtime on
LiveTV to have this bite them?  (I haven't looked at the current
LiveTV code at all.)  I'm assuming that this is also independent of
clock skew; if Myth couldn't tolerate even 1 second of skew between
MBE and FE, I assume we'd hear about it more.

    > > I have been using MythTV on a split frontend/backend since 0.18 (or

LiveTV in 0.18 uses a single possibly-giant ringbuffer, so presumably
NFS attribute caching wouldn't be nearly the issue it is in current
LiveTV.  I don't know how much LiveTV you use in modern releases.

    > Also, just a reminder, the MythTV backend, not the frontend, records and 
    > writes TV files to the storage directories.  As f-myth-users explicitly 
    > said that performance was unaffected when the client reads from the NFS 
    > server, a frontend's mounting a backend's storage using actimeo=0 is not 
    > going to cause a huge performance impact, since the frontend is reading, 
    > not writing, the data.

... unless your FE is also an SBE writing via NFS to the disks on the
MBE, which mine used to be.  Fortunately, that's not how I discovered
the enormous (for me, anyway) performance impact of noac/actimeo=0.

    > http://www.mythtv.org/wiki/Optimizing_Performance#Network_File_Systems

This doesn't seem to mention the business in "modern" kernels where
you might want to set an enormous rsize|wize, like a meg; did I miss
it?  If that should be added, it might also be good to add how you
determine that you're running that sort of kernel so people don't
set it wrong in either direction.


More information about the mythtv-users mailing list