[auto-schedule-restore] Auto-restore schedule after retune

martyzzz said:
I have auto-schedule-restore installed and it has never worked after a re-tune. Please advise what I might be doing wrong! I am just about to reprogramme all of my recordings - deep joy

Thanks
Click to expand...
I've often had this. The problem seems to be that it makes a backup on each stop or start cycle and thus can save a blank during the faff of retuning. The auto-restore then uses that latest backup ... meh.
I usually make a specific manual backup before tuning, do the retune, then manually restore the backup I made.
If you haven't got a manual backup, then view the recent auto backups, from the most recent backwards in time, until you find one that looks like what you need (it'll likely be only one or two back depending on how many cycles of standby you've done) and restore that.
(This is done with the tab in WebIf in the Recording Schedule pane.)
 
martyzzz said:
I am just about to reprogramme all of my recordings - deep joy
Click to expand...
There's never any need to reprogramme, even if auto doesn't work – the alternative is to do it manually via WebIF >> Scheduled Events >> Backup/Restore (unfortunately it's in very light text and you might not have realised it's clickable).

Check (ie set its radio button) a likely looking backup date and click View Backup to see what's in there. You then have to check it again (unfortunately) before you click Restore Backup.

The HDR-FOX then requires a reboot to action the restore, regardless of RTS setting.

martyzzz said:
Please advise what I might be doing wrong!
Click to expand...
Auto-schedule-restore only operates during a reboot, so if you don't reboot after the retune you will find the schedule empty. If you then add something (anything) to the schedule, it won't be seen as "empty" so auto-schedule-restore won't kick in at the next reboot.
 
Also if you have a power on / power off timer set in the UI, the Off timer is not lost on a retune so the schedule does not restore because it is not blank.
 
Last edited:
I wondered about that, but I wasn't sure. What about the OTA check schedule – is that ignored by ASR?
 
/mod/sbin/autoschedule
The event with name 'Disable OTA' is ignored when detecting an empty schedule, as well as reservations of type >= 7, but I can't recall what those are.

Otherwise...
MikeSh said:
I've often had this. ...
Click to expand...
+1, and for the work-around.
 
Thanks to all for your replies - the tip to do a manual restore worked well and saved a lot of time

I did force a reboot immediately after the retune so I don't think that can be the reason for the auto part failing. However, now I know the manual route I will do that in future

Thanks again
 
The logic of the /mod/sbin/autoschedule script is that if the schedule is empty any auto-saved schedule is restored, and otherwise the schedule is auto-saved. Why save an empty schedule over a possibly non-empty auto-saved backup?
 
To expand on this, take, for instance, the case of an uncommanded reset or retune, where the box reboots into the wizard. It seems that this happens when the tuning DB is somehow corrupted, and the tuning tables are either dropped or emptied. The auto-saved schedule is lost although it might have been useful if it survived (other flash files survive).

Either the box crashes and reboots, or reboots from standby, into the wizard.

If the tuning tables (in channel.db) were dropped, the ASR script would fail without restoring the schedule or saving a new backup. Then after retuning, the original autosaved schedule would be restored on rebooting. This isn't what happens.

If the tuning data is emptied, the ASR script considers the schedule to be empty and tries to restore the schedule. However the missing tuning data will prevent the restoration, leaving an empty schedule; the auto-saved file gets deleted and the system doesn't reboot. After retuning the new empty schedule is auto-saved. This is consistent with observed behaviour.

So let's (a) not delete the auto-saved file if the restored schedule is empty and (b) not auto-save an empty schedule.
 
So after today's uncommanded reset, this modified /mod/sbin/autoschedule was put to the test:
Code: 
#!/mod/bin/jimsh

source /mod/webif/lib/setup
require rsv.class system.class

set backup "/mod/boot/schedule.ab"

proc empty_schedule {{table tbl_reservation}{raw 0}} {
        set empty 1
        foreach event [rsv list $table] {
                if {[$event get ersvtype] < 7} {
                        if {$raw || [$event get szevtname] ne "Disable OTA"} {
                                set empty 0
                                break
                        }
                }
        }
        return $empty
}

if {[empty_schedule] && [file exists $backup]} {                              
        rsv restore $backup                                                   
        # Exit if the schedule is still empty following restore.              
        if {[empty_schedule pending]} {                                       
                #file delete $backup                                          
                system restartpending 0                                       
                exit                                            
        }                                                       
        loop i 1 4 {                            
                system display "Schedule..." "schd"                           
                sleep 1                                                       
                system display "...Restored" "rest"                           
                sleep 1                                         
        }                                                       
        system notify "The recording schedule has been automatically restored."
        system display "Rebooting..." "wait"                                   
        file delete $backup                                                    
        system reboot                                                          
        exit                                                                   
}
if {![empty_schedule] || ![file exists $backup]} {                             
        rsv backup $backup                                      
}
Results:
  • wizard completed with all expected channels, no favourite groups;
  • restart -> same;
  • then rEbt shown in HD Fox panel (must have missed Schd and rESt!);
  • after restart, favourite groups were restored, but (a) including unwanted empty groups (b) without custom group names.

Definitely better than before, but still with this issue.
 
v1.4 of the package (available shortly) backups up the schedule periodically (if necessary) rather than only at boot, so it should (almost) always be up-to-date.
 
After an uncommanded reset, the autoschedule restore operation did not seem to be run although a valid autoschedule backup file was present. Where is the 1.4 script called with restore?

I think it used to work like this:
  • the script is run as a cron job after the system restarts
  • if the schedule is empty and there is a backup, it tries to restore it and reboot the system, after deleting the backup to avoid a loop
  • if the schedule is not empty and/or (probably "and" would have been better) there is no backup, make a backup.
 
/df said:
if the schedule is empty and there is a backup, it tries to restore it and reboot the system, after deleting the backup to avoid a loop
Click to expand...

I don't see how it could work like that. There can be multiple backups, and what if it needed to be restored again?
 
This backup file is a special thing, different from those listed in the Backup/restore tab (or whatever it's called).
 
/df said:
Where is the 1.4 script called with restore?
Click to expand...
Oops. Something seems to have got dropped in the last update. Fixed.
if the schedule is not empty and/or (probably "and" would have been better) there is no backup, make a backup.
Click to expand...
It makes a backup regardless, every 5 minutes. Previously it only made a backup at startup which left a huge hole if you didn't reboot very often.
 
prpr said:
which left a huge hole if you didn't reboot very often.
Click to expand...
As I know only too well :D

So what's this "special" backup file? I didn't realise there was a separate one from those listed in the restore tab (ie those named "auto")! And if it's not those, what are those?
 
Whereas the Backup/Restore schedule is every night.

Obviously there is a need for historical backups as well as a last known good. I am sceptical about using a frequent backup here because I have seen empty scheduled backups being saved overnight when the next restart shows an "uncommanded reset".

Also, maybe the Backup/Restore list should list this backup too? But that might mean integrating this package into WebIf.
 
I never realised the auto-schedule-restore system was separate from the manual restore system, and I don't see why they should be.
 
My main HDR powered up into the startup wizard for the 2nd (or 3rd) time this year. One thing I noticed was that it rebooted itself while trying to scan for channels. It had only scanned roughly 20% before performing reboot. On the next startup the scheduled recordings was still empty so I've no idea why it rebooted by itself.
I know about the occasional startup wizard issue.
I don't understand why it rebooted during startup wizard channels scan.
 
You must log in or register to reply here.
Back
Top