That's assuming your desire is the right way. My opinion is that it is not. Rolling all units out at once would be a support nightmare and a disaster if issues creep up. You haven't given any reason IP based downloads would be any better than via the sat other than timing issues, and a free tuner/install when idle approach solves that.
Updates every night?
- Thread starter GaryPen
- Start date
- Latest activity Latest activity:
- Replies 41
- Views 6K
-
WELCOME TO THE NEW SERVER!
If you are seeing this you are on our new server WELCOME HOME!
While the new server is online Scott is still working on the backend including the cachine. But the site is usable while the work is being completes!
Thank you for your patience and again WELCOME HOME!
CLICK THE X IN THE TOP RIGHT CORNER OF THE BOX TO DISMISS THIS MESSAGE
That's assuming your desire is the right way. My opinion is that it is not. Rolling all units out at once would be a support nightmare and a disaster if issues creep up. You haven't given any reason IP based downloads would be any better than via the sat other than timing issues, and a free tuner/install when idle approach solves that.
As an IT professional I would say fix your code if it's that bad. This is Unix (really Linux in this case but that is splitting hairs) and rebooting should be the absolute last option.
Uptime should be measured in days / weeks or months not hours.
Just my input, and late at that.
Sent from my SAMSUNG-SGH-I777 using Tapatalk 2
Autohop doesn't. I've seen the icons added several times in the post 1am hours without a reboot. I agree, they should not have to reboot every night. I can see why they would like to do a dedicated fsck process at some interval, but nightly seems like overkill.
jm42:
I would say the option for both should be available.
With the cheap cost of non-volatile storage these days you could have 2 or 3 areas for images and recover without bricking the unit.
Further, i think the unit should ship with the initial software in a ROM for the ultimate in brick proofing.
B&N shipped the nook color with the shipping code in a ROM to make it nearly impossible to brick. everybody could learn from this example.
Sent from my MB855 using Tapatalk 2
I would say the option for both should be available.
With the cheap cost of non-volatile storage these days you could have 2 or 3 areas for images and recover without bricking the unit.
Further, i think the unit should ship with the initial software in a ROM for the ultimate in brick proofing.
B&N shipped the nook color with the shipping code in a ROM to make it nearly impossible to brick. everybody could learn from this example.
Sent from my MB855 using Tapatalk 2
That's because I am right. And, you are not.
Why would it be more of a nightmare than it is now? Issues always pop up. Every SW release has had one problem or another for some users, but not others.
If their CS dept was properly managed, and the CSR's properly trained, they could handle whatever is needed. If it turns out there was a problem with the SW, they could send out rollbacks. And, if it was via IP network, it could be immediate. They could even do it as a "hit", the way they send authorizations now.
Perhaps, if they didn't have so many issues with every release, this would be a moot point. But, that is a whole other issue with Engineering and QA.
Again just an opinion.
Instead of a measured rollout, you would have them blast an update out to everyone at once and have any unforeseen issue piss off the entire user base instead of an initial subset?
I'll be the first to admit Dish's QA leaves a lot to be desired, but even the best QA and extensive testing will miss something. An all at once release strategy would be foolish with as many moving parts as they have right now.
But again, there is nothing you've said that comes close to requiring IP based updates, other than possibly being a few minutes faster. As you've noted, they send commands via the sat stream routinely. I'm not against IP updates, but there are about 1001 things that should have priority over it.
I only see a small list of items that should take precedence ahead of IP updates, which will bring them into this decade, doing it like every other CE manufacturer.
Stability in all product being number one.
Standardization across all product lines being number two.
Education and skills training of employees being number three.
Of course, there is nothing preventing concurrent implementation.
Most other manufacturers don't have a choice. Make an ROI case for it. They need to fix the sat updates first so that it will apply to everyone. "Web updates" won't sell a single sub and adds virtually nothing to the user experience.
OTA, better apps, better hopper integration, fixing general bugs and stability, bluetooth support, a better on-demand experience, the keyboard remote will, official wireless support, manual timers, a large font UI, increasing the timer/event counters, better parental controls and other things I haven't even dreamed of would all add more to user experience and ultimately more value.
Each one of those break out into dozens if not hundreds of projects.
If direct ROI were the only motivation for doing things, we would have zero innovation.
IP updates are not innovative or necessary, and would be of only marginal benefit.
Assuming no checks are in place at the head end. Which would be shockingly easy to implement. Since rollout is by serial number of the hopper it would be fairly easy to do. Transfer? Take your pick, lots of options here and again not terribly difficult to implement. Scale? Doesn't scare me, but I'm used to working on enterprise level projects.
The people that implement this don't have to be the same people that write the mainline interface code. Perhaps Dish needs to look for a few good automation people
See above.
Requires no? Possible? Yes. You could even randomize the check times and monitor network activity to determine when things are quiet so as to minimize the impact to the customers WAN resources.
Since I'm not exactly part of this I wouldn't begin to say what's priority for Dish and what isn't.
Last edited:
It's not that it's hard to control, or that they couldn't do it. Gary was arguing they should send releases out en masse. For some updates they do that now. Doing it routinely is foolish. And again, how does IP based vs sat based make any difference at all here?
Anything is possible, but why? They have to have the sat update process. They cannot rely on IP. Any IP update process would be redundant. It's not a redundancy that is of any real benefit - updating via IP is useless if you can't see the sats. Why worry about WAN resources when your sending everything via the sat anyway? I can't imagine it being any priority at all.
JM:
Start thinking about the future where Dish has spectrum and for argument's sake we'll say they start distributing content via LTE. That would all be IPv6 based. IMO, the worst possible scenario is being stuck in an either/or instead of a multiple option solution.
As for priorities, I still don't know.
Start thinking about the future where Dish has spectrum and for argument's sake we'll say they start distributing content via LTE. That would all be IPv6 based. IMO, the worst possible scenario is being stuck in an either/or instead of a multiple option solution.
As for priorities, I still don't know.
I have to laugh... I went into the diagnostic system information (or I should say I tried to) to find what version of software I have on my Hopper, and it locked up on me. After I did a reset I tried it again and found I now have S221. So, if S221 is supposed to do something about lock ups, my confidence is not running extremely high at this time. Hahaahha
An LTE, IP only based "Dish" platform is at best 3 years away. Plenty of stuff to do before that. Again, I'm not against it, just see no need for it currently, no immediate benefit, and no justification that lack of IP updates is a shortcoming today. As you said, its not rocket science. I was designing/writing/deploying self-updating over the web/wan, business critical 24/7 services including complete automated server OS upgrades 15+ years ago when I had to account for half a dozen different connection methods from local internet dialup, to dial on demand routers, to wan connections and a T1 was practically cutting edge. Updating a receiver is childs play in comparison.
What problem would IP updates solve a free tuner approach wouldn't?
I have to agree that while nice to have, Internet updates should not be a priority.
Also, you would be shocked at the number of people that don't have broadband Internet, or if they do, do not have their receivers connected.
I know that you would leave the sat update as a backup for these people but I fail to see what an Internet update over a sat one would gain you.
If its a timing issue or the fact that they have to reboot to do the update all of this can, and will by the sounds of it, be changed in a future software release.
Also, you would be shocked at the number of people that don't have broadband Internet, or if they do, do not have their receivers connected.
I know that you would leave the sat update as a backup for these people but I fail to see what an Internet update over a sat one would gain you.
If its a timing issue or the fact that they have to reboot to do the update all of this can, and will by the sounds of it, be changed in a future software release.
