phil-news-nospam@[EMAIL PROTECTED]
wrote:
> On Sun, 04 May 2008 08:10:43 -0500 Jer <gdunn@[EMAIL PROTECTED]
> wrote:
> | phil-news-nospam@[EMAIL PROTECTED]
wrote:
> |> On Thu, 1 May 2008 20:17:34 -0500 Deke <no spam@[EMAIL PROTECTED]
> wrote:
> |>
> |> | Yes. And, at the same time, watch a program already recorded from
the hard
> |> | drive, SD or HD. So you are recording 3 HD programs, two from
satellite,
> |> | and one from OTA, while watching something else from the Hard
Drive.
> |> | Its an amazing machine. It kicks sand in the face of every other
DVR that I
> |> | know of. Plus you can add an external
> |> | hard drive, up to 750gb, without losing the use of the built-in
hard drive.
> |> | I'm using mine in single mode, by the way. The above features may
not be
> |> | available in dual mode, but who cares?
> |>
> |> I noticed that 750GB limit. I'd like to have a talk with the
programmers as
> |> to why they put that limit in place (or the managers if they are the
ones who
> |> did that). I happen to have a 1TB USB drive spare right now. There
are 2TB
> |> drives out now (they say the 722 does not support array drives, but
those can
> |> be set up to appear as one drive, so I don't know what the issue with
that is).
> |>
> |> What good programmers should do (and good managers not get in the way
of) is
> |> simply accept whatever size gets plugged in. I do understand why
they are
> |> encrypting the recordings keyed to the subscriber account. If the
drive is
> |> a 16TB drive that the USB standard _can_ handle NOW, and _will_ show
up at
> |> some point in the future, then their firmware code should just accept
it and
> |> use it all.
> |>
> |> Maybe they are limiting their code to 32 bit integers to index
sectors? If
> |> they did, they could do up to 2TB. Even if they were dumb and used
only
> |> signed 32 bit ints to do that, they could still go up to 1TB. The
750GB
> |> limit just doesn't make sense from a technical perspective. Someone
had to
> |> have made an aritificial decision to set that limit.
> |>
> |> I have a 1TB drive that is actually less than 1TB expressed in
binary. Even
> |> with signed 32 bit ints indexing sectors, the whole drive can be
accessed as
> |> it is just short of the full binary 1TB size.
> |>
> |> USB supports multiple drives connected through a hub. Why can't they
handle
> |> that? Bad programmers or bad managers again?
> |>
> |> Features I'd like to see that COST THEM MONEY (so I don't expect they
would
> |> do for that reason): connectivity for Firewire drives, eSATA drives,
CF cards,
> |> SDHC card, ... and even allow BURNING onto attached DVD or BR-DVD
recorders
> |> in the encrypted form that can only play back on the same account
(not on the
> |> regular players unless the player is attached through the recivers
associated
> |> with that account).
> |>
> |
> |
> | As a follow-up, I noticed this on the Dish website...
> |
> |
http://www.dishnetwork.com/content/our_products/user_guides_and_manuals/index.shtml
> |
> | Click on the "Linux Source Code" bar
>
> OK, they're running Linux as the underlying OS. That could explain the
disk
> reformatting. In the "misc" programs section, there is "e2progs" which
more
> strongly suggests ext2/ext3 formatting.
>
> Still, at least the files that are stored will be encrypted. It is also
> possible they could encrypt the whole disk (and that might be the cause
of
> their 750G limit). They are using Linux kernel 2.4.31 based on the
source
> file names. But I don't recall a 750G limit in that version of Linux.
>
> If they are doing the encryption only at the file level, and if it is
easy
> to identify files related together for one program (maybe one file, but
maybe
> in split files), I could still collect those files and archive the
programs
> on an individual basis in a larger storage system. I could also enable
USB
> gadget support on _my_ Linux have have it host the "external disk", and
get
> the files out of it as they come across.
>
Another old adage I remember is "the devil's in the details" and those
details may be embedded in the additional un-GPL code they use on their
DVR, hence their mention of that potential somewhere on that same page.
I didn't figure it would take long to get in way over my head on this.
:)
--
jer
email reply - I am not a 'ten'


|