• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

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

prpr

Well-Known Member
If you do an Automatic retune, any previous recording schedule is wiped out.
The C/F backs up the recording schedule once a day, so, when the machine boots, why can it not restore the latest recording schedule (if one exists and is not empty) if the current recording schedule is empty? This would ease the "do a rescan to update your channels" malarkey.
What does the panel think?
 
Or even better have it's own "update new channels" ... does this do anything apart from just update the databases tables?

i.e. if you can view the different tuned muxes, and remove channels from showing, could you add them - if you can't have it to scan the mux or read the current info. on the muxes could you add new channel details based on an external database of new channels?
 
I have thought this would be a good idea, but I am not clear how to determine whether the schedule is empty due to a retune or due to the user deliberately clearing the schedule.

If it was able to restore the schedule automatically (and it deletes unwanted channels now anyway), we would be able to let retunes happen as and when (goodbye disable-dso).
 
If you do an Automatic retune, any previous recording schedule is wiped out.
The C/F backs up the recording schedule once a day, so, when the machine boots, why can it not restore the latest recording schedule (if one exists and is not empty) if the current recording schedule is empty? This would ease the "do a rescan to update your channels" malarkey.
What does the panel think?


This, to me, is the biggest fault of the HDR T2. It is the one reason I use the Foxsat HDR rather than this for most recording. It retains the schedule after a re-tune.

Is there some way to ensure that a re-tune triggers a schedule restore? Or a reboot triggers a schedule restore? I know we can use the web interface to restore the schedule, but without automation at the hardware end this is hardly a viable recorder. How many users must have missed recordings because of this feature?
 
It would be possible to trigger a schedule restore on boot if, for example, there are no recordings or reminders. At present the backups are held on the hard disk and the schedule restore is written in Jim which means it has to occur once the system has fully booted and it would have to then trigger a reboot to fully restore the schedule. It could be rewritten in C so that it can occur during boot but I don't like duplicating code and the benefit of it being written in Jim is that it can use the schedule classes that are part of the web interface library.

There seems to be interest so I will write a package that implements this but leave it as an optional install for now.
 
I have thought this would be a good idea, but I am not clear how to determine whether the schedule is empty due to a retune or due to the user deliberately clearing the schedule.

If it was able to restore the schedule automatically (and it deletes unwanted channels now anyway), we would be able to let retunes happen as and when (goodbye disable-dso).

If the current channel list was also backed up at the time the schedule is, then if the “current” channel list is different [and the schedule is now empty] on reboot, I would assume/presume that a retune has occurred. Unless it will automatically retune without any real need to do so?

Could a “pretend” marker channel or some kind of change to an existing channel name (for example: append a space to BBC ONE) be added to detect retunes - it would be removed on a retune?
 
Channels can move, not just appear or disappear. This would prompt a retune without any new services appearing.

What concerns me (and I admit it would be rare) is that if the user were to deliberately clear out the recording schedule, next boot everything is restored.
 
What concerns me (and I admit it would be rare) is that if the user were to deliberately clear out the recording schedule, next boot everything is restored.
This is hardly a problem. Would you rather have a box that records things you don't want on very rare occasions, or a box that doesn't record things you do want whenever a retune needs to be done?
I know where my money would be.
 
Yes, it could be covered by user instructions to always leave a dummy schedule item (the daily EPG refresh / OTA defeat would be sufficient).
 
Channels can move, not just appear or disappear. This would prompt a retune without any new services appearing.

What concerns me (and I admit it would be rare) is that if the user were to deliberately clear out the recording schedule, next boot everything is restored.

I was thinking along the lines of saving everything (EPG#, mux, frequency, PIDs and so on) in order to detect a “retune”, and only restoring the schedule if a retune appears to have taken place. That would still leave the possibility of a retune happening, but there being no changes?

Or it might be possible to add special characters to a channel name (see above post), or even create a “pretend” channel (“NOT RETUNED”); such changes would presumably be deleted by an automatic retune?

Maybe there is something else in one of the .db that can be used...

The Webif could display a banner, which the user needs to acknowledge to clear, that a schedule restore has taken place.

If it isn’t possible/easy: if the schedule on boot-up is empty and the back up is not, save a copy of the backed up schedule and put a warning message on the Webif front page?

I am with prpr; I think it would be rare that we would deliberately clear the schedule and then retune. I'd rather potentially have some “odd” recordings than miss a load of stuff (or have family members miss something). The only issue to resolve would be updating the reservations to account for channel “moves” and the like; so a backup of the previous channel list is possibly required.
 
Yes yes yes I agree with all that - but I don't understand that it is a significant problem at all. All the major retunes have happened now and any future ones will only be minor fiddling that have no effect on existing recording schedules (other than delete them!). af123's restore process accounts for channel moves etc already (as best it can).

To have this auto-restore facility the user would need to be running the CF, therefore the user is also perfectly capable of disabling auto-retunes (thus rendering the need null and void). Consequently, unless it can be made seamless there seems little point. That said, I recently retuned HDR2 (outstationed supported user) and thought "no tuning issues, I'll do an auto-scan", then forgot to restore the recording schedule :oops:. I got some minor flack, but fortunately the user has an appropriate attitude "it's only telly".

I was thinking along the lines of saving everything (EPG#, mux, frequency, PIDs and so on) in order to detect a “retune”, and only restoring the schedule if a retune appears to have taken place. That would still leave the possibility of a retune happening, but there being no changes?

Or it might be possible to add special characters to a channel name (see above post), or even create a “pretend” channel (“NOT RETUNED”); such changes would presumably be deleted by an automatic retune?
It would probably have to be a complete image compare, because I don't think we can add entries to the database - only modify them. There might be a redundant bit somewhere that could be used as a flag.
 
I would imagine that someone who has installed an auto-restore package and wants to clear out their entire schedule, would probably do so via web-IF anyway, so they could then just do a manual backup at that point, to ensure that the auto-restore doesn't bring back everything they've just removed from the schedule. This could even be combined with a 'clear all and backup' button? The possibilities are endless(ish)...
 
auto-schedule-restore package now available. It restores the schedule on the first boot following a retune - indicates that it has done so on the front panel and reboots to commit the schedule.

In fact it checks whether the schedule is 'empty' on each boot. If it is not empty then it backs it up otherwise it restores it. Empty is defined as having no recordings or reminders in the schedule.
 
Is the auto restore file that is used the latest 'auto' back-up file? in other words, will it use a manually backed up schedule if it is newer?
EDIT
I think I can answer my own question now, It looks like the latest auto back-up is restored and a newer manual back-up will not be.
There are some WiKi notes HERE, they have been up-dated to show the info. in #16
 
auto-schedule-restore package now available. It restores the schedule on the first boot following a retune - indicates that it has done so on the front panel and reboots to commit the schedule.
Working very nicely thanks.
 
Is the auto restore file that is used the latest 'auto' back-up file?
No, it uses its own backup file stored in flash that is updated on every boot. It will be more up-to-date than the auto backups. You can restore a manual backup after a retune even with this package if you do it before rebooting.
 
Nice one af123 - just installed this package! With the amount of changes that seem to happen on Freeview I guess it won't be long before I get to try it out!

Many thanks.
 
Back
Top