[mythtv-users] Excessive disk usage in remotecache on Raspberry Pi

[Michael T. Dean]

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