Separate names with a comma.
Discussion in 'DIRECTV General Discussion' started by cypherx, Mar 6, 2013.
Go ahead and rub it in!:lol:
The problem with steeling engineers is that some could be under contract and most likely they signed NDA's anyway. A dish engineer jumps ship and they find out that's how DirecTV is getting new features... Can you say lawsuit?
Sure...I didn't mean to imply you would be well served by switching. From all I know, the Roku and AppleTV are roughly equivalent, except for AppleTV's better support of the "Mac ecosystem" as you called it. My intent was simply to say that for "non-Mac people" Roku is as good as it gets, at a much lower price point than AppleTV.
All of which is way off topic. :backtotop
Everyone yelled at me when I suggested that DirecTV's software development processes were fundamentally flawed, and would never lead to truly high quality software. Glad to see I'm still being proven right, even well after the highly vaunted HD GUI upgrade that would "fix everything."
I don't think EVERYONE yelled at you...
OK, a lot of people yelled at me.
First off, welcome back...you haven't posted in a long time.
What's your recommendations to improve the development?
Yeah hi Jeremy! Not sure if this is the same one from dslreports...
What would you think to individual one on one attention to each model HR to correctly optimize it for its SoC?
You know what we have now reminds me of the old Facebook iPhone app. It was ungodly slow, buggy and annoying. It was built in HTML 5 which was supposed to make it easier to update. However since there were so many performance complaints they rewrote an iOS optimized version. Now it runs super fast. Same hardware, same end result (accessing Facebook). Just now super speed.
Thanks. I'm just stopping by though, I'm still a very happy Comcast customer with a Tivo DVR. It may lag sometimes, but it always lags in the same places and it always responds to remote input.
I do have the same username over there.
I think that abstracting out the code so that they can optimize for each SoC individually would definitely help the performance issues. But the other stuff, like bugs that seem to pop up all the time, points to a deeper flaw in methodology. Without having more specific information about how they work, it's hard to say anything of value about what they could change.
It's not directly related to the software development, but the decision to allow different hardware architectures within models that are supposed to be related was very shortsighted. Probably one of the biggest mistakes DirecTV has made in the development of their own hardware/software platform.
Well I can't speak for that personally, as I do not have a HDD on my 211k.
However, it's pretty pathetic that all my "older technology" E* DVR's (722k's & even a 522 I'm getting ready to send back) ALL run circles around any D* DVR, speedwise... :eek2:
It was SO nice to go to DVR's that actually do something, like NOW - when you press a button on the remote!
I've never used a Directv DVR, only the receivers. Is there noticeable lag between the time you hit controls like FF, play and pause to the time it actually acts on it? That would be highly annoying. My Tivo Premiere may have a GUI that's slower than I'd like for doing stuff like navigating the menus, but it responds instantly to the types of controls you use when watching a program. Even my now DOA 10 year old Series 2 responded instantly.
A DVR would be practically worthless for doing stuff like skipping commercials or finer grained things like skipping the gaps between plays in a football game if there's any lag in response to the remote.
There is some lag more so on an MRV client. I would be curious this response time on a Joey or TiVo mini.
I wanted to come back to this comment.
I think one of the main reasons Dish equipment is so much faster and more consistent is that they use one mfg to produce them all. So each and every box is exactly like every other box with that model number. And having that mfg be a company tightly tied to Dish doesn't hurt either.
With D* using different mfgs to produce the boxes, and end users noting the differences in performance and reliability by mfg, it seems obvious that for the customer, farming out the mfg might not be in our best interest. It certainly is for D* as I would think they'd get some competition for the build contracts.
While every mfg that makes a D* box should be working on a single spec, it doesn't seem that it is quite that way with them trying to cut costs to increase their bottom line. That in turn makes writing code a bit more daunting to compensate for these, probably minor, differences.
I'm betting that there's no JVM (there's no compelling reason for it in a proprietary environment) and there couldn't be a worse engine than the one they were using. Even if that were the case, database engines and JVMs shouldn't interfere with operations that don't involve databases or "apps".
Aren't these things capable of mult-threading? The CPU on the HR44 is dual core, but I'm not so sure about the others. Maybe they should of put like a PowerVR or AMD mobile graphics co processor to further offload the daunting task of display writes off of the CPU.
Multiple manufacturers could of been given a spec to adhere to for performance and I/O. I mean you can buy a PC from HP, Dell, Sony, Acer and many others. They don't seem to suffer so poorly multitasking on a full operating system like Windows 7 running aero or Windows 8 running metro.
compelling reason ... yeah, tell me that after reading system log from your external drive ...
Drawing analogies to PCs is a questionable practice. The DirecTV DVRs use highly integrated processors that wrap a CPU, video processing, tuner interfaces and many low level DVR functions up into a single chipset (and on the later units, a single chip). Whether a particular function is slow because of the higher level application code, bottlenecks in the system, or contention for resources may be difficult to determine and certainly impossible to determine from simply using the DVRs.
That the DVRs can be very sluggish is certainly undeniable, but diagnosis of why is pure conjecture.
The display writes are already handled by a separate section that handles character rendering and graphic scaling/overlay.
If you look at the relatively large amount of non-CPU computing power and storage resources, it is little wonder. Most modern computers have more resources in their display adapter than a modern DVR has all tolled and power consumption to go with.
Applying general purpose computing theory to a consumer DVR is absurd and should not be engaged in.