[mythtv-users] Excessive disk usage in remotecache on Raspberry Pi
Michael T. Dean
mtdean at thirdcontact.com
Sat Dec 3 16:09:44 UTC 2016
On 12/02/2016 07:27 PM, Mike Holden wrote:
> Bear in mind that if you mount directories using the noatime option,
> which is quite common, the access time of the files will never be
> updated, so this will likely delete everything after 7 days!
>
> Alternative options in find would be -mtime, which is the
> creation/last modified time.
This will likely be the same result as using a not-updated atime, since
the file is created (ctime/mtime/atime all equal), then never modified
by MythTV (no mtime updates--we don't ever modify these, though some
bookmark thumbs might be replaced if the user changes the bookmark), and
only accessed (so atime is updated on file systems where it's enabled).
I'd still say atime would be better since otherwise, even if a user
mounts his file system with atime enabled, he'll always lose the cache
after only 7 days. Therefore, using atime gives the best of both
worlds. Those with atime enabled get its benefit. Those who don't get
the same result as if it were implemented to use mtime. I don't like
the idea of implementing an atime equivalent in our database--seems a waste.
Peter, I highly suggest a quick test for your own benefit to see just
how much of a difference the cache makes (on different systems,
including but not limited to the pi). Just start up a frontend with a
good cache and go to Watch Recordings and scroll through a bit. Then,
exit the frontend and rm -r ~/.mythtv/remotecache , and restart
mythfrontend and go to Watch Recordings and scroll through a bit. You
should see a noticeable difference--even on a more-powerful system. We
actually got questions/complaints about how slow MythTV is from users on
fast frontends when they had misconfigured their ~/.mythtv to be
non-writable (i.e. they had it pointed to /etc/mythtv, but the user
didn't have write permissions on it, so they didn't get their caches).
So, deleting too aggressively will affect performance.
Also, there's no need to clean up the themecache. We currently have it
set so that it's created when you change themes, and we keep one (?)
other one--the one you were just using--in case you change back/because
generally people will switch between only a couple if they even switch
at all.
Then again, we could just recommend a system script to clean it up (in a
monthly cron job or frontend startup/shutdown script or ...) and let
"the user" (or, for some, the distro packager) decide what's most
appropriate.
Mike
More information about the mythtv-users
mailing list