Scheduled Backups - a few issues...

[birdman]

I have my box set-up do take backups at 22:00 (but see * below for more on that).
So if I'm watching via the box at 22:00 I get a pop-up window asking me whether I want the backup to go ahead. This is annoying - as I've already configured it to be made at that time, so obviously I want it to go ahead.
There is no way to switch off this prompt.

So, is there any possible reason why I might not wish a backup to be made at the time that I have asked it to be made? If not, I'll fix the code (BackupManager.py and src.xml in vix-core) to add an option to enable the backup to be run with no prompt.

I suppose another option might be to set a Power Timer for (say) 06:00 to 06:15, going to deep standby after the event and set the backups to run at 06:05, but I'm not sure what would happen if there were a recording running at that time. or what would happen if the box didn't need to be woken up (I already have a timer to put it into deep standby after 20 mins in standby, but this takes some apparently random number of hours to take effect).

* - backups at 22:00.
This is true. Here is an excerpt from my settings file:
config.backupmanager.repeattype=weekly
config.backupmanager.backupretry=30
config.backupmanager.scheduletime=22:0
config.backupmanager.backuplocation=/media/usb/
config.backupmanager.schedule=trueand here are the backups that are actually being taken:
root@mbtwin:/media/usb/backup# ls
openvix-mbtwin-Apollo.142-2015-02-10_22-00.tar.gz
openvix-mbtwin-Apollo.142-2015-02-11_22-00.tar.gz
openvix-mbtwin-Apollo.142-2015-02-12_22-00.tar.gz
openvix-mbtwin-Apollo.142-2015-02-13_22-00.tar.gz
openvix-mbtwin-SoftwareUpdate-Apollo.138-2015-02-10_15-43.tar.gz
root@mbtwin:/media/usb/backup#
So although I have weekly backups configured - they are actually being done daily!!! Weird. The code looks as though it should be OK - but obviously is not.

[birdman]

Update...

I've made the prompting before running a backup optional (default=yes, as that is the current setting). 2 lines added, one line modified.

I know why the weekly backups are done daily!
It's because the code assumes that the box is permanently up. It never remembers the time of the last backup, so always schedules one when it starts. Since mine goes into Deep Standby daily it gets a new backup scheduled for the next hh:mm after it starts - so daily.
But I also have the code fix for this. I put it in place on my box last night (well early this morning..) and it seemed to be working OK with the testing I did then. It remembers the last backup, and schedules the next one based on that. If the item for the next one has passed when the system boots up it will submit one to run after 60s.

One more thing I'll look at is auto-deleting backups (oldest to go first) so as to leave only n of them.

[birdman]

Well, a week on and my weekly backup has run OK and scheduled then next backup for a week hence.

I'll post the code changes when I have time.

[birdman]

OK.
Here's the code to:

stop the box prompting you to do the backups, which you have configured it to do (default is to continue to prompt)
remember the time of the last backup across reboots (==Deep Standby) so you only get what you've asked for. If you've missed one (box off too long) it will be run 60s after booting up. (As a result of how this works you will get a backup at boot up the first time you run this code, as it will think you've missed one - or rather missed every one since 01 Jan 1970....)

The patches are against BackupManager.py and setup.xml in vix-core.

The zip file contains the two updated source files and the patches/diffs against the current standard code.

40986

[birdman]

I've now written the code to only keep the last n backups (0 == keep them all, and is the default).
So I can now go back to daily backups and only keep the last 12, without having to manually delete some from time to time.
Note that the backups done for a software update are included, as they end up in the same location, with the same prefix and suffix.

Here is all of the code (including the changes made in post #4): 41276

[birdman]

Minor (well - major) problem with an indentation level there, which meant that if you had fewer backups than the maximum you said to keep then they were all deleted (a "feature" which from then on would always leave you with none...).

Here's the corrected code: 41298

(There doesn't seem to be any way to delete an uploaded file?)

[birdman]

I see that this (the final, corrected version) has been added to Apollo 156 (or 154+).

So now I'll go back to looking at Bookmarks/Locations...