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

[Peter Bennett]

On 12/03/2016 11:09 AM, Michael T. Dean wrote:
> 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.
>
I would rather set it to 30 or 60 days, or make it dependent on
remaining disk space in some way.

> 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.
>
I will try that.

> 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.
>
I agree, the themecache is not one to be cleaned up. The other caches
seem to be quite small so probably nothing needs to be done there.

> 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.
>
For now that is all they can do. It will be a a while before I get
around to doing anything on this. Before I start I will create a
developer task ticket and anybody can make suggestions there.

> Mike