<div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2019, 1:21 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 23 Apr 2019 22:28:26 -0400, you wrote:<br>
<br>
>On Tue, Apr 23, 2019 at 8:44 PM <a href="mailto:jam@tigger.ws" target="_blank" rel="noreferrer">jam@tigger.ws</a> <<a href="mailto:jam@tigger.ws" target="_blank" rel="noreferrer">jam@tigger.ws</a>> wrote:<br>
><br>
>><br>
>><br>
>> On 24 Apr 2019, at 4:24 am, <a href="mailto:mythtv-users-request@mythtv.org" target="_blank" rel="noreferrer">mythtv-users-request@mythtv.org</a> wrote:<br>
>><br>
>><br>
>> Having the script in /etc/cron.daily doesn't seem to be functional, I'd<br>
>> like to have the database optimize itself just before the nightly<br>
>> auto-shutdown. What is a good way to accomplish this?  It's mythtv fixes<br>
>> 0.29 on Ubuntu desktop 18.04.  TIA  Daryl<br>
>><br>
>><br>
>> You say having the script in /etc/cron.daily is not functional, but you<br>
>> haven't entirely explained what you mean by that.<br>
>><br>
>><br>
>> I’ve run mythtv for many years<br>
>> I’ve some thousands of videos<br>
>> I’ve some tens of recordings and some 100s of deleted<br>
>> I’ve never run optimise.<br>
>><br>
>> I ran optimise and it completed in 15 odd seconds, so why not have<br>
>>  an ordinary reboot cron entry?<br>
>><br>
>> James<br>
>> ______________________________________<br>
>><br>
><br>
>After a few days of normal use, I start seeing momentary freeze ups in<br>
>playback, while the optimize script is in cron.daily. Running it from the<br>
>terminal clears things up, doing it automatically, after the days<br>
>recordings would be ideal.<br>
<br>
If the optimize_db (database optimise/repair) or mythtv-database<br>
(database backup) scripts are allowed to run at the same time as you<br>
are playing something in mythfrontend, then you can get significant<br>
slowdown in the response times from mythfrontend, and in the worst<br>
case you can get playback pauses.  It depends on the size of the<br>
database, and what is stored where.  If you are trying to play a<br>
recording that is on the same disk as the database, you will get the<br>
worst effects.  With a huge database like mine, you can get problems<br>
with recordings as well.  If I have more than one recording running<br>
while those scripts are running, I will get damaged recordings.  I am<br>
not sure of the exact mechanism, but it may be due to writes to the<br>
database (especially to the recordedseek table) not working properly.<br>
<br>
Since my MythTV box is on 24x7, I have scheduled the scripts to run at<br>
a time when I will never be watching anything and when it is very<br>
unlikely that there will be more than one recording happening.  In<br>
Ubuntu 18.04, that required that I fix a bug that changed when anacron<br>
was running things - they started being run just after midnight, which<br>
is often a time when I have several recordings happening.  Anacron<br>
used to be run at a much better time, 07:30, in older versions of<br>
Ubuntu.<br>
<br>
Originally, anacron was run from the /etc/cron.d/anacron script.  That<br>
script still exists and is still run at 07:30, but does nothing as it<br>
now has a check to see if systemd is being used and if so it exits<br>
without running anacron.  In Ubuntu 18.04, anacron is now run from<br>
these two systemd units:<br>
<br>
/lib/systemd/system/anacron.timer<br>
/lib/systemd/system/anacron.service<br>
<br>
The anacron.timer unit runs the anacron.service unit once per hour,<br>
with a randomised 5 minute delay.  The anacron program itself does a 5<br>
minute delay before it does anything, and it also checks to see if it<br>
has already been run today before it runs the daily scripts (and<br>
similarly for the weekly and monthly scripts).  It does that by<br>
storing the last time it ran those scripts in files in<br>
/var/spool/anacron (cron.daily, cron.weekly, cron.monthly).<br>
<br>
The net result is that in Ubuntu 18.04 (and later???) anacron normally<br>
gets run once per hour and it will normally only do its daily tasks<br>
the first time it is run on any given day.  If the PC is running 24x7,<br>
that means anacron is run at a time randomly selected within 5 minutes<br>
after midnight, and 5 minutes after it is started it will run the<br>
daily scripts in /etc/cron.daily.  If your PC is not on 24x7, the<br>
first time it is booted after midnight, anacron will be started after<br>
a randomised delay of up to 5 minutes after it boots, and it will then<br>
delay 5 minutes before it runs the daily scripts.  That is not a good<br>
way to run optimize_db and mythtv-database, as it means they will<br>
normally be run while a recording is happening, or while you are<br>
trying to watch a recording.<br>
<br>
To make anacron work the same way it used to in earlier versions of<br>
Ubuntu, you need to override the anacron.timer file with a systemd<br>
override file.  The easy way to do that now is to do this command:<br>
<br>
sudo systemctl edit anacron.timer<br>
<br>
which will bring up your system editor to create a file in<br>
/etc/systemd/system/anacron.timer.d.  In that file, put something like<br>
what I have:<br>
<br>
[Unit]<br>
Description=Trigger anacron at 09:30.<br>
<br>
[Timer]<br>
OnCalendar=<br>
OnCalendar=09:30<br>
RandomizedDelaySec=0s<br>
Persistent=true<br>
<br>
I have chosen to run anacron at 09:30 daily, as that is an even better<br>
time for me than the original 07:30.  You can choose any time you like<br>
in the above settings, and anacron will be run at that exact time.<br>
When anacron runs, it will delay doing anything by its usual 5<br>
minutes.<br>
<br>
With this sort of fix in place, if your system is being shut down<br>
between recordings, anacron will still be run on the first boot up<br>
that happens after the time you select.  It will wait 5 minutes, then<br>
actually run all the scripts, which is not good as by then MythTV will<br>
likely be busy with a recording or playback.  During that 5 minute<br>
delay, you can just kill anacron if you want to.  Using this command<br>
should do that:<br>
<br>
sudo pkill anacron<br>
<br>
If you kill anacron before it starts running scripts, there are no bad<br>
side effects.  When it is next run, it will run all the scripts that<br>
should have been previously run.  So that is what I normally do if I<br>
ever have to reboot my MythTV box after midnight and before anacron's<br>
scheduled run time at 09:30.<br>
<br>
If anacron has already started running scripts, then if you kill it,<br>
you will also kill all the scripts it was running, and if they were in<br>
the middle of doing something, you can get problems.  At the very<br>
least, there can be temporary files left behind, so it is best to<br>
avoid that unless you know how to check on what the scripts were doing<br>
and manually clean up any messes that got left behind.<br>
<br>
If you do not have a good time to allow anacron to automatically run<br>
optimize_db and mythtv-database, you could look at using my "gaps"<br>
script:<br>
<br>
<a href="http://www.jsw.gen.nz/mythtv/gaps" rel="noreferrer noreferrer" target="_blank">http://www.jsw.gen.nz/mythtv/gaps</a><br>
<br>
to work out when you have a gap in recordings that is long enough. But<br>
if you are shutting down the PC when it is not in use by MythTV, then<br>
probably the best way to run optimize_db and mythtv-database is to use<br>
some variant of Peter Bennett's mythshutdown.sh script, and remove<br>
them from the cron.daily and cron.weekly tasks completely.<br>
_______________________________________________<br></blockquote></div><div dir="auto"><br></div><div dir="auto">Thanks Stephan, I do have a gap between 7 and 8 pm. and this sounds like the more elegant way to go forward. I will implement in a few hours.</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>