[mythtv] Time taken for pruning cache

[Peter Bennett]

On 10/13/2017 11:36 AM, David Hampton wrote:
> On Fri, 2017-10-13 at 16:44 +0200, Piotr Oniszczuk wrote:
>> Guys,
>>
>> I see ongoing process of opening of myth to new code contributions
>> (which is finally great!)
>>
>> Will You consider to back port some of MiniMyth2 patches to myth tv
>> master code?
>>
>> I’m using mm2 patch set in my production system without any issues
>> since years while enjoying greater functionality&flexibility.
>> Also whole mm2 community runs them with great success I believe.
>>
>> If You think it is worth to do - we can discuss patch-by-patch here
>> and dev team can decide - is it worth to merge or not.
>>
>> So lets try with first candidate:
>>
>> https://github.com/warpme/minimyth2/blob/master/script/myth-master/my
>> thtv/files/0324-disable-caches-pruning.patch
>>
>> Patch allows to disable cache pruning by setting UIDiskCacheDays to
>> -1.
> Sure, I'll add support to disabling pruning by setting the value to -1.
>   I'm also willing to change the seven day default to whatever the group
> thinks is reasonable.  One or two months also seem like reasonable
> values.
>
>> Why useful:
>> If frontend is used as appliance with sleep/resume regime with mode
>> where mythfrontend process is exited at sleep and started at
>> appliance resume - cache pruning can considerable increase
>> mythfrontend start time (on my ION2 it is 11->19..21sec).
> I don't see times anywhere near that on my test machine, but you're not
> the first person to report new startup/shutdown delays.  Thanks for the
> feedback.
>
>> Sure - this we can overcome by moving cache pruning to separate
>> thread (which is also good idea IMHO)
> I agree this is a good idea.  I'll have to investigate whether it will
> require some sort of locking between deletion and cache lookups, or if
> we can get away without the locking.  I think I'll probably also need
> to disable the cache pruning on exit.
>
> David
>
>> But I have another argument to turn-off pruning some cases:
>>
>> lets see 2 cases:
>>
>> a\ no pruning:
>> (-)bigger disk usage
>> (+)no issue with lagging some images on UI (no cache)
>> (+)quick, predictable start of frontend
>>
>> b\pruning
>> (+)space on hdd saved
>> (-)noticeable UE impact when playing with UI
>> (-)mythfrontend startup sometimes so longer(*) than user thinks it
>> hanged
>>
>> For me in mm2 b\ wins clearly.
>>
>> Patch allows to user to decide a\ or b\
>>
>> (*) I have appliances where mythfrontend wasn’t restarted by weeks.
>> Any restart triggers long (10-20sec) of cache pruning.
>>
>> br
>>   
>>
I still wonder why the pruning is taking so long. My previous method of 
pruning was to remove the cache directory when my disk became full (on 
raspberry pi). That only takes a second, so why would removing part of 
the cache take up to 60 seconds? Perhaps there is excessive access to 
the directory to find out last accessed time, and maybe another way 
would be better. Alternatively, based on my experience, if you just 
remove the entire cache at some interval the slowdown on restart after 
that may not be noticeable.

If it really has to take a long time a possible solution -
- Stop the pruning after some fixed time (e.g. 10 seconds). The logic 
could then go on with another 10 seconds of pruning the next time you 
shut down or start up.

Peter