Problem deleting time expired event.

Trev

The Dumb One
I have a problem getting rid of an out of date sheduled event using the web I/f. (haven't tried from the box yet)
What I do:

Goto sheduled Events
Delete a time expired event
Hit the reboot
Wait
100% on bar but "Page cannot be displayed" error on browser (IE11)
Refresh browser page after a while then webif displays
Web IF comes up with Warning. "You have pending system notifications: "
"The recording shedule has automatically restored"
Yes it has. The event that I deleted is still there.
So I can't get rid of the out of date event, and why does it come up with the Page cannot be displayed error. It never used to do this.
Have I borked it somehow?
 
...
and why does it come up with the Page cannot be displayed error. It never used to do this.
Have I borked it somehow?

Mine will periodically do this. I just assumed it was a case of the browser had sent a refresh request before the server had properly restarted after the reboot. Sometimes it comes up alright, but other times even though the slider has reached 100% and the TV/radio has been showing a valid channel for 10s of seconds, the browser still can't get the page.
 
Web IF comes up with Warning. "You have pending system notifications: "
"The recording shedule has automatically restored"
Yes it has. The event that I deleted is still there.
Sounds like you're trying to delete the only event. This will trigger the schedule restore code on next boot as it thinks you've had a retune.
 
I've got the Disable OTA event and the (undeleted) Walking the Nile. It is the latter that I am trying to get rid of via the CF.
 
Disable OTA events don't count. You can't delete the other single event using the Webif unless you disable the auto-schedule-restore package.
The other option is to delete it using the TV UI rather than the Webif, then force a backup (/mod/sbin/autoschedule).
 
Thanks for the explanation, I'll do that and remember it for the future, perhaps. I don't have a major 'thing' about it but just wanted to know if it was normal or not.
 
It is probably unusual to have such an empty recording schedule.

I tend to schedule recording for most of our normal TV watching even if we do end up watching it live much of the time, it gives us the flexibility in case we decide to stay out, handle phone calls and other interruptions and to skip the ads.
Batch deleting a bunch of unneeded recordings at the end of the day is no real hardship and I like seeing the highlighted entries in the EPG as a reminder of whats on today.
 
It is probably unusual to have such an empty recording schedule.
That's the way that you do it, but not the way I do it. What about, in the CF, if you delete the last scheduled event as I did, then the CF automatically saves a backup of the empty schedule list so that the restore restores the empty list (except for the Disable OTA schedule)?
 
Yeah, my schedules have 20-odd entries....

That's the way that you do it, but not the way I do it. What about, in the CF, if you delete the last scheduled event as I did, then the CF automatically saves a backup of the empty schedule list so that the restore restores the empty list (except for the Disable OTA schedule)?
Just one of those things to get used to with the CF, if you want the auto-restore feature in case a DSO event wipes the schedule. You could just ignore that there are expired entries in the schedule - I do.

Alternatively, turn off auto-restore. With disable-dso installed the risks are pretty low.
 
Great, so you have got twenty odd. I have none now. But the zero event scenario is perhaps not quite as smart as it might be. Just a thought? :)
It's a bit like calculations that do division and the author didn't think about the outcome of the division if the divisor is zero on the grounds that it very rarely is.:eek:
Enough already!
 
What about, in the CF, if you delete the last scheduled event as I did, then the CF automatically saves a backup of the empty schedule list so that the restore restores the empty list (except for the Disable OTA schedule)?
Seems reasonable to me.
 
I was afraid of ridicule because I hadn't thought it through. But having the seal of approval of prpr is like getting an award from the Queen:roflmao:
 
But the zero event scenario is perhaps not quite as smart as it might be. Just a thought? :)
It's only a thought if you can think of an alternative solution.

The only way we have thought of to detect that a retune has occurred is to check if the schedule is empty. When the disable-ota package was upgraded to add the back-stop reminder entry to the schedule if it was missing, that broke the auto-restore: the schedule was then never empty. This was solved by ignoring the disable-OTA entry when checking for an empty schedule.

Like I said: turning off auto-restore is low risk, and solves your problem.
 
Like I said: turning off auto-restore is low risk, and solves your problem.
But it's not the optimal solution. That is the one that has already been proposed. I've tested it (deleting the /mod/boot/schedule.ab file) and it works.
 
I was afraid of ridicule because I hadn't thought it through. But having the seal of approval of prpr is like getting an award from the Queen:roflmao:
I'm not totally convinced about whether a) you think I'm worthy of granting seals of approval or b) you're just extracting the urine.
 
prpr said:
But it's not the optimal solution. I've tested it (deleting the /mod/boot/schedule.ab file) and it works.
I wish I knew WTF you were talking about. Does that stop the 'problem' that I indicated in my first post?

I've just thought it through and other for tidiness and idiot trapping (such as myself) it could be tidier, but I haven't a clue how. As I don't have a stack of entries in my schedule list, there is no point in restoring nothing, so removing auto-restore is even less of a risk than BH suggested in Post #13.
prpr said:
I'm not totally convinced etc.
It's a not b. And that's not a Boolean expression but perhaps a bit OTT
 
But it's not the optimal solution. That is the one that has already been proposed. I've tested it (deleting the /mod/boot/schedule.ab file) and it works.
I don't get you. Is this what you mean as "already been proposed"?:
The other option is to delete it using the TV UI rather than the Webif, then force a backup (/mod/sbin/autoschedule).
Backing up an empty schedule doesn't solve the problem - it just means that every boot the auto-restore will kick in and restore an empty schedule, then (maybe, not sure) prompt the user to do a reboot (via WebIF). If the user then adds something to the schedule, that will be auto-backed-up and the cycle is broken, but next time the user has no entries in the schedule it will be back to square one. How is that optimal?

If you have a solution which works in all cases and is fit-and-forget, I'm sure we would all like to know about it (and roll it into the CF). If all the user wants is to be able to tidy up a schedule that only contains Disable-OTA plus expired entries, then turning off the auto-restore is the only option as far as I can see, never mind an optimal one.
 
But if the schedule contains the Disable DSO event, then it ain't really empty, is it? It's got the Disable DSO in it. Does it matter if the CF restores an 'empty' schedule at every boot. It's the reboot popup on the CF that I am whingeing on about.
 
But if the schedule contains the Disable DSO event, then it ain't really empty, is it?
Call it empty for the sake of discussion. It's a bit long-winded saying "empty except for the Disable-OTA entry" every time (you mean Disable-OTA, not Disable-DSO)!

Does it matter if the CF restores an 'empty' schedule at every boot. It's the reboot popup on the CF that I am whingeing on about.
The one causes the other (thanks for confirming).

As I don't have a stack of entries in my schedule list, there is no point in restoring nothing, so removing auto-restore is even less of a risk than BH suggested in Post #13.
Not so: presumably you do sometimes have something scheduled to record, so auto-restore is protecting those occasions from a DSO event that happens to slip past the disable-dso defences (yes, I do mean DSO).

For readers needing help re DSO and OTA, see Preventing External Events from Disturbing the CF (click)
 
Last edited:
Ok. Disable OTA it is then. My BAD.
I appreciate that one causes the other, but I was wondering whether there is a way around it other than by your suggestion. The point I was obviously not making is the fact that it is not empty, it contains DOTA (if you have it set) after you have deleted the last 'real' event but the CF acknowledges the fact and treats it, at boot time' as if it were empty by ignoring the DOTA event. (As I understand it. Probably wrongly)
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'?

But when a change is made from the box, the box is directly writing to 'where the Hummy uses it from'. I also assume that a retune will get rid of all entries in the table, including the DOTA entry.

1. 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?

2. 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.

Option 1 seems favourite to me.
BH said:
Not so: presumably you do sometimes...
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. And it's a fudge as prpr said in post #14.
 
Back
Top