Why Can't Slow Receivers be Fixed?

Discussion in 'DIRECTV HD DVR/Receiver Discussion' started by socal404, Mar 4, 2012.

Thread Status:
Not open for further replies.
  1. Mar 6, 2012 #41 of 446
    Mike Greer

    Mike Greer Hall Of Fame

    1,612
    15
    Jan 20, 2004
    Salt Lake...
    Probably about right....

    I'm not sure on the hardware differences either... Yep - the 622 came out in March of 2006 - I had one for a couple of years - they started MPEG4 with the locals if I remember correctly.

    The only 'wrath' headed your way would be from people that can't handle the truth!
     
  2. Mar 6, 2012 #42 of 446
    Mike Greer

    Mike Greer Hall Of Fame

    1,612
    15
    Jan 20, 2004
    Salt Lake...
    Speaking of wrath... You know, another step in the direction of fixing slow receivers would be...

    To have 'testing' of new software done by someone other than the die-hard fans and the engineer's mothers!:lol:

    If DirecTV engineering received and listened to honest criticism from 'un-biased' users we would be way ahead of how things are today.
     
  3. Mar 6, 2012 #43 of 446
    sigma1914

    sigma1914 Well-Known Member

    14,716
    395
    Sep 5, 2006
    Allen, TX
    Naysayers (not an intended insult) like yourself and others are more than welcome to do CE testing.
     
  4. Mar 6, 2012 #44 of 446
    Mike Greer

    Mike Greer Hall Of Fame

    1,612
    15
    Jan 20, 2004
    Salt Lake...
    Not taken as insult... But to me it doesn't seem like the CE process works. I don't see how the current problems that will be fixed 'soon' got through the process.

    I think the biggest problem is that they don't want to hear about 'slow' for 48 hours and by the time the slow creeps back in the receivers are rebooting again for the next version.

    Maybe they should change it so the CE is once a month?
     
  5. Mar 6, 2012 #45 of 446
    veryoldschool

    veryoldschool Lifetime Achiever Staff Member Super Moderator DBSTalk Club

    42,754
    378
    Dec 9, 2006
    Let's not go down this road in this thread/forum, please.

    "I'm sure" there are decisions made that some may not agree with, and pressures that we don't know about.
     
  6. Mar 6, 2012 #46 of 446
    rb5505

    rb5505 Legend

    207
    1
    Dec 23, 2004
  7. Mar 6, 2012 #47 of 446
    TomCat

    TomCat Broadcast Engineer

    4,153
    101
    Aug 31, 2002
    Too little, too late.
     
  8. Mar 6, 2012 #48 of 446
    TomCat

    TomCat Broadcast Engineer

    4,153
    101
    Aug 31, 2002
    !rolling
     
  9. Mar 6, 2012 #49 of 446
    TomCat

    TomCat Broadcast Engineer

    4,153
    101
    Aug 31, 2002
    Actually, no, I think many here including myself welcome your help and perspective. But they ARE slow, and none of what you suggested makes much difference, unfortunately. They are what they are. At the end of the day, compared to other DVRs, they're slow!
     
  10. Mar 6, 2012 #50 of 446
    TomCat

    TomCat Broadcast Engineer

    4,153
    101
    Aug 31, 2002
    No wrath, I save that for trolls. You're obviously a smart guy, VOS, and I respect you greatly. But on this point you apparently have a fuzzy understanding of what actually goes on here. It's not a point of shame to be uninformed, especially if you are willing to course correct when you are.

    MPEG decoding of any flavor is not memory-intensive, in fact the only memory involved is the buffer inside the decoder chip. And again, that is a decoder chip, meaning all of the horsepower it needs to decode is right there on board. Compressed video goes in one side and decoded video comes out the other, and there is no load from that process impinging on the CPU running the GUI whatsoever.

    The decoder runs on its own. Its smart about decoding, and dumb about everything else; it sees voltage and it starts trying to decode whatever is on the input and spitting out video and audio on its output. It neither receives nor obeys instructions; it just sits there and decodes or attempts to decode based on a hard-coded script until the power goes out.

    And the workload on the HDD is actually less due to a lower mbps than MPEG-2.

    The coders for DTV are not "bad" coders, but as some have said, they simply lack the skill. It's a rare skill, BTW; pro systems face the same challenges, but they fix it not with more-clever coding, but with high-dollar hardware. They throw money at it rather than expert coders. These days it takes about 3 racks full of enterprise-class HP Proliant servers to handle video recording and playback on a professional level, where unexpected pauses in the GUI can't be tolerated.

    Your DVR is not a toaster. It is not as simple as an analog VCR. When I first started in electronics school they told me that even including PCs the basic garden-variety TV set was the most technically sophisticated item you could own outside of NASA, by a couple orders of magnitude over anything else.

    And even with iPads and smart phones and HDTVs, the same could be said today for your DVR. It is actually a remarkable piece of technology, and does things that were technically unimaginable only 15 years ago. And it does them pretty darned well. Unfortunately, the DTV DVRs do it just a little slower than some others do.
     
  11. Mar 6, 2012 #51 of 446
    veryoldschool

    veryoldschool Lifetime Achiever Staff Member Super Moderator DBSTalk Club

    42,754
    378
    Dec 9, 2006
    You're right. Some things I know to the core, while other things not so well.
    When I watch a video conference on the aspects/implementation of HD by industry leaders, and they point out the cost factor of needing more memory per unit to move to MPEG-4, "I believe them".
    In the simplest analogy, MPEG-2 video on a PC could be done with 64 megs of onboard memory. MPEG-4 video cards [to work with DirecTV2PC] require 256 megs min, and 512 megs recommended.
    I cut my teeth on airborne electronic warfare systems, so I didn't start with "toasters" either.
     
  12. Mar 7, 2012 #52 of 446
    Mike Greer

    Mike Greer Hall Of Fame

    1,612
    15
    Jan 20, 2004
    Salt Lake...
    Yikes – did you all just feel the chill in the air?!:)
     
  13. Mar 7, 2012 #53 of 446
    harsh

    harsh Beware the Attack Basset

    22,429
    384
    Jun 14, 2003
    Salem, OR
    This is done entirely in custom hardware. You're completely missing the dividing line between what is done as a CPU process and what isn't.
     
  14. Mar 7, 2012 #54 of 446
    veryoldschool

    veryoldschool Lifetime Achiever Staff Member Super Moderator DBSTalk Club

    42,754
    378
    Dec 9, 2006
    And you're still missing the load on the memory, that doesn't get the magically, but at this point... what is the point? :confused:
    This all started with someone comparing how well a HR10-250 works compared to the HR2x, and "how good" TiVo codes verses what DirecTV does.
    Apples, oranges, and lemons, until someone compares the THR22 to a HR21/22. Then the next thing to look at is what does one do that the other doesn't.

    The firmware resides in a chip not much bigger than a BIOS chip.

    Now maybe some TiVo users can reply about where the TiVo software resides, as "I think" it's on the hard drive.
     
  15. Mar 7, 2012 #55 of 446
    JonW

    JonW Icon

    526
    0
    Dec 21, 2006
    Given TV technology originated in 1920 using vacuum tube technology, I think they umm exaggerated. ;)

    TVs do use mixed signal technology, much like our DVRs include a satellite receiver and PC tech, but that's really not a great hurdle for either device.

    It's no longer enough for a piece of consumer equipment to do it's job, it must also do it very responsively. Anything less is simply no longer acceptable in this day and age.
     
  16. Mar 7, 2012 #56 of 446
    JonW

    JonW Icon

    526
    0
    Dec 21, 2006
    Which doesn't really mean anything other than that BIOS's have become bloated with features such as quick-boot-versions of Linux and that the cost of a flash ROM chip is reasonably low.

    The original IBM PC BIOS used to fit in what ... 8 K bytes? Of course it was written in assembly language.

    According to RedH, the DVRs are using anywhere from 16.1MB (HR20) up to 20.5 MB (HR34).

    Basically they've managed to fill up the equivalent of 2 entire IBM-XT's hard disks with firmware code.

    True that's not much by modern PC operating system standards, but for an embedded system it's still quite a lot.
     
  17. Mar 7, 2012 #57 of 446
    veryoldschool

    veryoldschool Lifetime Achiever Staff Member Super Moderator DBSTalk Club

    42,754
    378
    Dec 9, 2006
    That's the install file size, but the firmware is down round 1 Meg [wish I remembered the exact statement, in a chatroom several years ago].
     
  18. Mar 7, 2012 #58 of 446
    BoostedBlazer

    BoostedBlazer Cool Member

    19
    0
    Feb 15, 2012
    Best response I can form on this is, for all intensive purposes the R22 was never "intented to be an HD DVR" it was and still is considered a SD DVR that was created to operate in MPEG-4 transitional markets. It's capable of handling the signal in HD but not designed for it. Still one of my Fav boxes though! They're tough!
     
  19. Mar 7, 2012 #59 of 446
    Mike Greer

    Mike Greer Hall Of Fame

    1,612
    15
    Jan 20, 2004
    Salt Lake...
    The R22 is an HR22 with a different model number.... EXACTLY the same hardware.

    The HR22 was never intended to be a DVR at all if you ask me!:lol:
     
  20. Mar 7, 2012 #60 of 446
    Mike Greer

    Mike Greer Hall Of Fame

    1,612
    15
    Jan 20, 2004
    Salt Lake...
    Not sure what you mean by 'install file size'?

    It it realley down to 1 meg? That's pretty tiny!
     
Thread Status:
Not open for further replies.

Share This Page

spam firewall

Advertisements