DTV Blockheads -- Update in the middle of autotune??!!

OK, where the OP said "messed up recordings" I thought it was a DVR. Sorry.

As for the trivial check, all they have to do is a basic if. When they fork into the procedure that puts up the manual "I want to update, yes/no" window before they even draw the question just check if the box is doing some other user-initiated action. Generally a procedure returning anything other than 0 is an exception, it's as easy as something like:

cleartoupdate() {
if { duringaschedulerevent || dvrisrecording} then return 1
else return 0;
}

The receiver already knows if it's doing something because the scheduler made it do it (whether that's an autotune or a recording), and when those events start or stop. When the firmwareupdate procedure launches when the check comes back with 1 instead of 0 it exits until the next day. In fact, the receiver already has an exception handler available for it to process the user clicking "no" on the request box, so they'd just return to the firmware update routine with the same code they would process as if the user clicked "no".

Interesting...

But, how do you know what other code is being run, or if your statement would work if all the other parameters that are running? You don't.

So you have returned a true/false statement. How does that interface with the rest of the code. What you have written may work, but how do you know what else is happening? You don't. So your code, as a stand alone, works as a stand alone...

It's meaningless. Unless you have the rest of the code available for testing. Or are you telling us you are a DirecTV programmer...

Is that you Earl??

But here's what's going to get you... You don't have the code. And it would appear, at least at this time, DirecTV is not going to make "refusing/delaying" an update an option. They want all units on the same firmware. By giving the user and option to delay or refuse an update, they could end up with many users on different code.

And I'm sure you are saying "well, they can program it so you can refuse/delay the update just so many times" Just how much programming should they have to do to accommodate a small amount of users that are autotuning at 3:53am?

So, you are DirecTV and are updating an area of the country's receivers. You want this area to be done first, just in case there are problems. You have users that like the current version and start delaying/refusing the update. And it just so happens this update is to fix an an unseen, background programming that could cause problems with these receivers. You must now, keep the update in the stream for these users. You can not move on to another area because you have to wait for all the current areas receivers to be updated. But how are you going to know who has what version? Not all receivers are connected to land lines. So forcing a call back after update is not an option.

And since some have delayed/refused the update, your tech support people are now swamped with calls because the problem you were attempting to fix has now become a major issue because users have delayed/refused the update..

And now we are back to my original post... Isn't it better to have the update happen at 3:53am instead of 8:53pm?

SledDog said:

Interesting...

But, how do you know what other code is being run, or if your statement would work if all the other parameters that are running? You don't.

Click to expand...

Don't need to - the receiver already does.

So you have returned a true/false statement. How does that interface with the rest of the code. What you have written may work, but how do you know what else is happening? You don't. So your code, as a stand alone, works as a stand alone...

Click to expand...

Don't need to. They already have the interface - it pops up a message "OK to update?" already. They should, as part of that already existing code, the check for the scheduler and return a "no not now" just like it would have if the user was there to click no when the window popped up. It's a couple of additional lines of code in a routine that's already launched.

But here's what's going to get you... You don't have the code. And it would appear, at least at this time, DirecTV is not going to make "refusing/delaying" an update an option. They want all units on the same firmware. By giving the user and option to delay or refuse an update, they could end up with many users on different code.

Click to expand...

They already GIVE the user the ability to cancel the update if they happen to be watching the screen at the time it wants to launch.

Thinking it through a bit more, they must already do some sort of this collision detection in the DVR series because I've never had either my HR10 or HR20 kill a late-nite (or early morning depending on how you look at it) during previous software updates to those units.