- major trigger - standby mode (100% chances to do the night reboot);
- if there is scheduled recording activity going in background - delay reboot and wait for true standby status,
That much is already being done. While recording the receiver will not automatically reboot.
And I have completely missed a reboot on a night when I've told it no every hour or had recordings all night long.
- if OS missed night window - postpone it for next night,
- after X days of skipping the reboot - give a warning to the customer about soon happening reboot as mandatory action and propose to provide by him a time of a day or next night in true standby mode (in case of non-response [say, on vacation] - do force reboot).
Once a receiver is targeted for an update it is best that it takes the update. Not only do some of the "bugs" get fixed but there can be new features that DISH is relying on getting deployed. There is no time (unless the receiver crashes or the user forces a reboot) that the receiver will reboot during a recording.
Are you proposing that the receiver stay on for several days straight with no nightly reboot? Rely on the customer always turning off the receiver to put it in standby every night?
psmith is right, the stb looks to updates every few hours (4 I believe) and fills itself in accordingly.
Are you talking about EPG updates? If that statement were true for EPG updates new channels that were added during the day they would have their full EPG within four hours. Customers are not getting full EPG for new channels until the next day (after the nightly reboot and EPG download). The data is there ... as anyone who has forced an EPG download can attest ... but the receiver is not looking for a full update 24/7.
Firmware updates only come when in standby.
I'm sure they will problably eventually address the udpate time but maybe its a little more complicated than everyone thinks. I'm guessing that when you have clients relying on a host then the timing must be perfect in the way they power down and fire back up so that there are no issues when they all come back online.
I hope they do. And threads like this bring it to DISH's attention that there is an issue with the way the nightly reboot is implemented.
I would believe that having Joeys in the picture might complicate things but the thing is my Joey almost never reboots at the same time as the Hopper it's linked to. If it's such an issue then the linked Hopper/Joey pair should synchronize their update times if they're ever different.
If it were up to me Hopper and Joey would never reboot at the same times. With the network down during the Hopper reboot the Joey's reboot would not finish until the Hopper was back up and running.