Night reboot

[John Kotches]

My guess is that there are a couple of reasons. Like a computer, which it is, it clears out the memory. Also it is easier to have the receiver check for software updates than have Dish tell the receiver it needs to reboot for a software update. Maybe DIRT can get the answer from engineering.

It is a computer, it isn't "like a computer". It runs a MIPS processor with an unknown to me (because I can't login) variant of Unix.

You have been to the Microsoft school of troubleshooting... Where a reboot is the first step of troubleshooting instead of one of the last things you do.

Its time for Dish to think of Hopper as the server it is and not as if it were a desktop of a casual user that doesn't rely on it for a living.



Sent from my SCH-I605 using Tapatalk

 

[John Kotches]

My guess is that there are a couple of reasons. Like a computer, which it is, it clears out the memory. Also it is easier to have the receiver check for software updates than have Dish tell the receiver it needs to reboot for a software update. Maybe DIRT can get the answer from engineering.

When I get home, I will post a snippet of shell script that would demonstrate just how easily they could mange n - 1 software and not reboot nightly.



Sent from my SCH-I605 using Tapatalk

 

[carpexnoctem]

It's not going to interfere with a recording by definition of disrupting it where it stops and then resumes when it comes back online, resulting in a split. What we're getting at is ever since S342, it now intrudes with the update message while you're recording. It's stupid that this was changed because it still waits until you're not recording to actually update. If you are recording and tell it 'Yes' to update, all it does is go into standby mode and wait until nothing is recording. Essentially you have just reserved a slot for a future update and locked yourself out from watching TV in the meantime. This is annoying to those of us who like to watch TV in the early a.m. hours while recording. It's frustrating because I purposely leave it more than enough hours each night where I don't have anything recording and it rarely wants to update during those times. It will often ask while I'm recording the last two minutes of a show, and if I tell it 'No' the message prompt won't appear for another half hour or more when if it would have just waited two minutes, I would have told it 'Yes' so it could have updated. It's counterproductive to have to try to schedule several HOURS free every morning just so it can have better chances of updating when the update itself only takes a few MINUTES. That exact scenario is happening right now as I post this. I left it a generous window from 1:30 a.m. until 3 a.m. to update, but it never bothered to ask. Now the update opportunity has ended for now since I'm recording a show again at 3 a.m.

 

[John Kotches]

So I promised this yesterday, but I didn't get to it...

Anyway:
3 directories for Hopper:
/firmware/hopper/queued
/firmware/hopper/applied # After being applied it goes here.
/firmware/hopper/applied-1 # Previous version.

3 directories for Joey:
/firmware/joey/queued
/firmware/joey/applied
/firmware/joey/applied-1

3 directories for SuperJoey:
/firmware/sjoey/queued
/firmware/sjoey/applied
/firmware/sjoey/applied-1

All new code lands in the appropriate devices queued directory (firmware/''device''/queued):

Code consists of the software bundle and an md5 checksum. You use the md5 checksum to insure the bundle payload transferred successfully.

dev=`command to distinguish between hopper/joey/sjoey`

# No MD5 or firmware bundle, no action taken.
[ ! -f /firmware/$dev/queued/*.md5 ] && logger "$dev: no software update"
[ ! -f /firmware/$dev/queued/*.firmware ] && logger "$dev: no software update"

Verify firmware with md5sum
[ md5sum /firmware/$dev/queued/*.firmware != `cat /firmware/$dev/queued/*.md5` ] && logger "$dev firmware failed md5sum" ; exit 1


# We have firmware and it checks so let's try to apply it. do our housekeeping.


# Apply firmware
# Dish code goes here to apply firmware, don't know what it entails.

# Non-zero exit means application failure.
[ $# -ne 0 ]  && reapply_applied if needed ; logger "$dev: reapplied prior version" ; exit

# Successfully applied, do housekeeping.
# Applied becomes applied-1
rm /firmware/$dev/applied-1/*
mv /firmware/$dev/applied /firmware/$dev/applied-1
mv /firmware/$dev/queued /firmware/$dev/applied

Note: This is just an example and I'm sure I'd write it a little bit differently when I'm in a vi session instead of cold typing code into a forum reply window. Bottom line, it ain't difficult.

 

[John Kotches]

It's not going to interfere with a recording by definition of disrupting it where it stops and then resumes when it comes back online, resulting in a split. What we're getting at is ever since S342, it now intrudes with the update message while you're recording. It's stupid that this was changed because it still waits until you're not recording to actually update. If you are recording and tell it 'Yes' to update, all it does is go into standby mode and wait until nothing is recording. Essentially you have just reserved a slot for a future update and locked yourself out from watching TV in the meantime. This is annoying to those of us who like to watch TV in the early a.m. hours while recording. It's frustrating because I purposely leave it more than enough hours each night where I don't have anything recording and it rarely wants to update during those times. It will often ask while I'm recording the last two minutes of a show, and if I tell it 'No' the message prompt won't appear for another half hour or more when if it would have just waited two minutes, I would have told it 'Yes' so it could have updated. It's counterproductive to have to try to schedule several HOURS free every morning just so it can have better chances of updating when the update itself only takes a few MINUTES. That exact scenario is happening right now as I post this. I left it a generous window from 1:30 a.m. until 3 a.m. to update, but it never bothered to ask. Now the update opportunity has ended for now since I'm recording a show again at 3 a.m.

It is disruptive to Joey viewers when the linked hopper reboots. But I guess they don't matter.

The "it's only a few minutes" is an excuse for any number of issues, and if my answer was to reboot the systems I managed daily I'd quickly be unemployed.

Hoppers are servers, and Joey's/SuperJoey's are clients. They need to be treated as such.

 

[Jim S.]

Never mind the server argument, why shouldn't they be able to program ANY receiver to not need a daily reboot?

 

[GaryPen]

Well it's not checking for updates at the 1:30 nightly - none of the last few updates on either of my HWS were downloaded at that time, both were closer to 11 pm & midnight, interrupting my normal tv watching. Turned on tv & system was in process (for 20 minutes or more) on the 342 one.

Got a negative response from someone on the Dish forum about "still complaining", as he said the nightly reboots are the way Dish wants it & it will never change, it really doesn't cause anyone a problem ("it's only for two minutes!"). Can't believe anyone in their right mind doesn't see that as an issue. Having your paid tv interrupted everynight, every hour, while you are trying to watch is a definite problem for those of us who stay up late. Especially when there's no need for it to be at 1:30.

The Dish Defenders will always be there to argue with those who post legitimate complaints and annoyances. It's like you called one of their kids ugly.

 

[Archangel00]

NEVER, EVER, in my life have I had a DVR, hell ANY device for that matter, that REQUIRED, nay FORCED, a reboot/restart every 24 hours until I had the great misfortune of having to choose Dish as my TV provider...

Computers? EVERYTHING is a computer these days! What the hell would you think if every car on the road at 1:30 am had to reboot!!! LOL Here's an idea, change all the microwave ovens in the Dish break rooms so they reboot half way through cooking everyone's hot pockets...LOL Maybe one of the reasons it takes Dish's code monkeys so long to do anything, and why what little they do manage to get done is so screwed up, is that their workstations are rebooting whenever they feel like it? LOL

Processing guide data? WTF does it need to shutdown to do such a mundane task as this! Especially when EVERY OTHER DVR ON THE PLANET doesn't need to...ONLY Dish equipment requires that!

Seriously, is Dish where SKYNET begins? Don't know that I've ever seen a piece of hardware that is so far outside the control of it's human users and creators...

 

[John Kotches]

Never mind the server argument, why shouldn't they be able to program ANY receiver to not need a daily reboot?

It's a mentality, especially for those of us who manage *nix systems and don't expect a reboot to be a normal first step in troubleshooting.

 

[carpexnoctem]

The nightly update time frame begins at about 1 a.m. with 6 a.m. being the cut off. The last time range it will ask is about 5:30 a.m. I've confirmed that if you allow the update when the message pops up by telling it 'Yes' it will go into standby mode and continue to record underneath. If you're not around or are unable to answer, it will also go into standby mode and continue to record underneath. I've had this happen both from not being around to respond and also when the message came up unexpectedly while I was navigating the Guide and unable to select either of the options from the prompt. The obvious disadvantage is you can no longer watch TV without disrupting the process. The advantage is as I've said before, you have essentially reserved a ticket guaranteeing an update. One morning I had recordings going until 6:45 a.m. but I had allowed the update and as soon as all recording finished, the receiver powered down for the update even though it was well past the cut off time. One thing gathered from the nightly updates is it downloads current artwork and images for shows and movies. If you cancel the update too many times to where it doesn't update ever or you don't leave it for a few undetermined hours on screensaver mode after it powers back on from an update, you will find that you're missing artwork for certain shows and movies. Sometimes the entire week for certain channel listings can be blank and the shows will record saved with a Dish Network logo in place of the appropriate images. Whether this is of importance to you or not depends on your opinion of the visual aspect of the Hopper. I like the graphics except when inaccurate or outdated because you're at the mercy of what Tribune Media Services supplies. Overall, this tells me that until they implement a way to manually set our own time for updates, they need to go back to how it was before. I've had a non-HD receiver and a ViP 722k and after upgrading to the Hopper with Sling I was stunned that there was no way to manually choose my own update time. I assumed this to be a standard feature from Dish.

 

[ChadT41]

I'm honored that Peggy mentioned me on here. As far as the "fix" goes. It requires something that isn't scheduled by design to be "fixed". This is not a big, but it is something that is done intentionally. With the former recievers, people were not letting it update. Then mad because the guide was not up to date. Dish took this ability away with the hopper. My point is, if not satisfied with the product, do not use the product. But this is how dish has designed this specific peice of equipment. It may change in the future. I have heard through the grapevine that it is likely to change in the near future, however, as it stands currently, the 2-5 minute update isn't enough for me to hate the equipment. And yes, 130 is a primary time I'm watching tv. I get the frustration, but that just makes it time to do something else. My viewing experience does not hinge on this feature, and it only updates once per day. I am not someone that gets mad when something goes against dish, I just think there are better things to really discuss, such as the dish anywhere user experience. The codec is just fine with the hopper.

 

[lucky86]

Why they don't allow you to completely skip the update, yes, so the box software remains current. I'll bet we eventually see the update time become customizable of at least changeable. We probably haven't seen it yet for multiple reasons, one of which is probably technical regarding the way everything would have to shut down and be staggered, as well as staggering of the power up cycle.

I guess only time will tell.

Posted Via The FREE SatelliteGuys Reader App!

 

[charlesrshell]

I'm honored that Peggy mentioned me on here. As far as the "fix" goes. It requires something that isn't scheduled by design to be "fixed". This is not a big, but it is something that is done intentionally. With the former recievers, people were not letting it update. Then mad because the guide was not up to date. Dish took this ability away with the hopper. My point is, if not satisfied with the product, do not use the product. But this is how dish has designed this specific peice of equipment. It may change in the future. I have heard through the grapevine that it is likely to change in the near future, however, as it stands currently, the 2-5 minute update isn't enough for me to hate the equipment. And yes, 130 is a primary time I'm watching tv. I get the frustration, but that just makes it time to do something else. My viewing experience does not hinge on this feature, and it only updates once per day. I am not someone that gets mad when something goes against dish, I just think there are better things to really discuss, such as the dish anywhere user experience. The codec is just fine with the hopper.

Thanks for the information. And how are you in the know with your first post in this forum? Are you a new DIRT member?

 

[dwarren2]

2-5 minutes is a lot better than the hour or more it used to take when I had a 722 with an ehd. Then it did a a complete system check at every reboot.

 

[Tony S]

If the Dish software engineers don't think that it is worth it for us to be able to set the update time, why can't they schedule the update FOR A LATER TIME than 1:30am when many people are still viewing. If they moved the time to 3:30am I think that far less people would be affected. (It still would be a problem for some though; I really can't understand why the engineers can not make this simple change to the software).

 

[dwarren2]

If the reboot time is time zone related, a 3:30 am would also have ramifications. That would mean rebooting at 6:30 eastern time. Many nationally broadcast channels are well into their daily schedule. That would cause a significant interruption on the west coast.
So, I think that a user should be able to schedule a time that works for them, if the default does not.

 

[peggy97850]

It's easy to say "My point is, if not satisfied with the product, do not use the product " but Dish is predominately installing only Hoppers these days, along with a required 2 yr contract. Once installed, you're stuck with the nightly interruption that you pay a premium for. I was told (by a Dish rep on the Dish forum, others were too) "it's coming in a future software upgrade" well over a year ago, my mistake was believing he knew what he was talking about & upgrading to a 2nd HWS last summer.

OP used to work for Dish. He got people so riled up on the Dish forum (on this topic) that threads had to be locked down to get people to stop posting & at least one was banned.

 

[charlesrshell]

If the reboot time is time zone related, a 3:30 am would also have ramifications. That would mean rebooting at 6:30 eastern time. Many nationally broadcast channels are well into their daily schedule. That would cause a significant interruption on the west coast.
So, I think that a user should be able to schedule a time that works for them, if the default does not.

I am in Central time zone and the daily reboot time is usually fairly consistent around 1:30 AM CST for me. What time do your reboots take place for EST?

 

[Tony S]

EDIT: Deleted double post (see below).

 

[Tony S]

I am in Connecticut and the daily update is the same time, 1:30AM. If the update time is 1:30 for all time zones, I think that 3:30 would be a better time for most. (However, as I said previously, it still would be a problem for some; I really can't understand why the engineers can not make the simple change to to allow us to choose the update time).