Problem deleting time expired event.

[Black Hole]

I assume that when a change is made to the table in the CF, a boot is necessary to get it copied to 'where the Hummy uses it from'?

Yes, the database cannot be modified with the humaxtv process running, which is why all WebIF and RS mediated schedule alterations are queued until the next boot, and why you get a warning in the WebIF to tell you there are queued alterations that need a reboot to be incorporated into the database.

But when a change is made from the box, the box is directly writing to 'where the Hummy uses it from'.

Yes, because the Humax firmware has the necessary ownership of the database file.

I also assume that a retune will get rid of all entries in the table, including the DOTA entry.

Yes.

So at boot, if DOTA is present in the table, but no other entries, then do nothing otherwise (e.g. no entries at all in the table because of an errant retune), or multiple entries, do what's done at present. This obviously won't work if the user has not set the DOTA timer event, so do what is done now. Possibly a better solution as only DOTA has to be set for it to work without torturous delete at the box and disable auto restore at the CF?

We've already been around this loop (before you got an HDR-FOX). Because of the order things have to happen in, by the time auto-restore gets to looking at the schedule the disable-ota package has already added the schedule entry. Thus the auto-restore has to ignore the Disable-OTA schedule item.

Or what about if the CF set a flag when you make a change with the CF that empties the table and then at boot time, the CF checks the flag and if set, does nothing and if not set do what it does now. Flag is cleared by having entries in the table. I have not thought through full implications of that you might delete the entry from the box mainly because of lack of understanding of how the CF interacts with the std. FW.

Maybe. AF will have to think about that one. It won't work if you clear the schedule via the SUI.

It was you who said "Like I said: turning off auto-restore is low risk, and solves your problem." Now you are saying "Not so:".?????????????? I'm confused.

removing auto-restore is even less of a risk than BH suggested in Post #13.

I said it was low risk, not zero risk.

 

[Black Hole]

I think I might have thought of a way:

What if the disable-ota package sets a flag if the schedule is completely empty when it looks. The auto-restore process could then act on the flag rather than checking the database all over again, IF the disable-ota package is installed and configured to add a schedule entry if missing.

<sigh> That's no good either. Forget I said it.

 

[Trev]

And I implied that it was lower risk than what you implied. Neither of us implied that it was zero risk

 

[Black Hole]

What's lower than low, other than zero?

 

[Trev]

Very low seems to fall nicely between low and zero.