[mythtv-users] optimize before shut down

Daryl McDonald darylangela at gmail.com
Wed Apr 24 16:34:41 UTC 2019

On Wed, Apr 24, 2019 at 7:20 AM Daryl McDonald <darylangela at gmail.com>

> On Wed, Apr 24, 2019, 1:21 AM Stephen Worthington <
> stephen_agent at jsw.gen.nz> wrote:
>> On Tue, 23 Apr 2019 22:28:26 -0400, you wrote:
>> >On Tue, Apr 23, 2019 at 8:44 PM jam at tigger.ws <jam at tigger.ws> wrote:
>> >
>> >>
>> >>
>> >> On 24 Apr 2019, at 4:24 am, mythtv-users-request at mythtv.org wrote:
>> >>
>> >>
>> >> Having the script in /etc/cron.daily doesn't seem to be functional, I'd
>> >> like to have the database optimize itself just before the nightly
>> >> auto-shutdown. What is a good way to accomplish this?  It's mythtv
>> fixes
>> >> 0.29 on Ubuntu desktop 18.04.  TIA  Daryl
>> >>
>> >>
>> >> You say having the script in /etc/cron.daily is not functional, but you
>> >> haven't entirely explained what you mean by that.
>> >>
>> >>
>> >> I’ve run mythtv for many years
>> >> I’ve some thousands of videos
>> >> I’ve some tens of recordings and some 100s of deleted
>> >> I’ve never run optimise.
>> >>
>> >> I ran optimise and it completed in 15 odd seconds, so why not have
>> >>  an ordinary reboot cron entry?
>> >>
>> >> James
>> >> ______________________________________
>> >>
>> >
>> >After a few days of normal use, I start seeing momentary freeze ups in
>> >playback, while the optimize script is in cron.daily. Running it from the
>> >terminal clears things up, doing it automatically, after the days
>> >recordings would be ideal.
>> If the optimize_db (database optimise/repair) or mythtv-database
>> (database backup) scripts are allowed to run at the same time as you
>> are playing something in mythfrontend, then you can get significant
>> slowdown in the response times from mythfrontend, and in the worst
>> case you can get playback pauses.  It depends on the size of the
>> database, and what is stored where.  If you are trying to play a
>> recording that is on the same disk as the database, you will get the
>> worst effects.  With a huge database like mine, you can get problems
>> with recordings as well.  If I have more than one recording running
>> while those scripts are running, I will get damaged recordings.  I am
>> not sure of the exact mechanism, but it may be due to writes to the
>> database (especially to the recordedseek table) not working properly.
>> Since my MythTV box is on 24x7, I have scheduled the scripts to run at
>> a time when I will never be watching anything and when it is very
>> unlikely that there will be more than one recording happening.  In
>> Ubuntu 18.04, that required that I fix a bug that changed when anacron
>> was running things - they started being run just after midnight, which
>> is often a time when I have several recordings happening.  Anacron
>> used to be run at a much better time, 07:30, in older versions of
>> Ubuntu.
>> Originally, anacron was run from the /etc/cron.d/anacron script.  That
>> script still exists and is still run at 07:30, but does nothing as it
>> now has a check to see if systemd is being used and if so it exits
>> without running anacron.  In Ubuntu 18.04, anacron is now run from
>> these two systemd units:
>> /lib/systemd/system/anacron.timer
>> /lib/systemd/system/anacron.service
>> The anacron.timer unit runs the anacron.service unit once per hour,
>> with a randomised 5 minute delay.  The anacron program itself does a 5
>> minute delay before it does anything, and it also checks to see if it
>> has already been run today before it runs the daily scripts (and
>> similarly for the weekly and monthly scripts).  It does that by
>> storing the last time it ran those scripts in files in
>> /var/spool/anacron (cron.daily, cron.weekly, cron.monthly).
>> The net result is that in Ubuntu 18.04 (and later???) anacron normally
>> gets run once per hour and it will normally only do its daily tasks
>> the first time it is run on any given day.  If the PC is running 24x7,
>> that means anacron is run at a time randomly selected within 5 minutes
>> after midnight, and 5 minutes after it is started it will run the
>> daily scripts in /etc/cron.daily.  If your PC is not on 24x7, the
>> first time it is booted after midnight, anacron will be started after
>> a randomised delay of up to 5 minutes after it boots, and it will then
>> delay 5 minutes before it runs the daily scripts.  That is not a good
>> way to run optimize_db and mythtv-database, as it means they will
>> normally be run while a recording is happening, or while you are
>> trying to watch a recording.
>> To make anacron work the same way it used to in earlier versions of
>> Ubuntu, you need to override the anacron.timer file with a systemd
>> override file.  The easy way to do that now is to do this command:
>> sudo systemctl edit anacron.timer
>> which will bring up your system editor to create a file in
>> /etc/systemd/system/anacron.timer.d.  In that file, put something like
>> what I have:
>> [Unit]
>> Description=Trigger anacron at 09:30.
>> [Timer]
>> OnCalendar=
>> OnCalendar=09:30
>> RandomizedDelaySec=0s
>> Persistent=true
>> I have chosen to run anacron at 09:30 daily, as that is an even better
>> time for me than the original 07:30.  You can choose any time you like
>> in the above settings, and anacron will be run at that exact time.
>> When anacron runs, it will delay doing anything by its usual 5
>> minutes.
I just removed the system event and implemented this fix, usually my system
starts for the 6pm news and records at will untill 11pm, the box logs on
automatically, so it is ready for us in the evenings and I log off before
retiring for the night. There is normally a gap between 7 amd 8 pm so I
chose 19:30 for anacron.



Description=Trigger anacron at 19:30


When I wrote out I wasn't offered the path I expected
(/etc/systemd/system/anacron.timer.d.) rather an alpha/numeric sequence, I
now suspect they were the tailing sequence: (#override.confd50a7936adc6c1fe)

I'll know if this is indeed the solution in a week or so by the presence or
absence of momentary freeze ups. Thanks to all!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20190424/13d3e012/attachment.html>

More information about the mythtv-users mailing list