'Humax Freeview HD receiver outed'

On Mon, 28 Sep 2009 01:24:35 -0700 (PDT), 2Bdecided
wrote:

On 27 Sep, 22:38, Chris Hogg wrote:
On Sat, 26 Sep 2009 13:53:41 -0700 (PDT), 2Bdecided

There are various tools for getting the MPEG-2 video and audio out
of .ts files. DGindex will do it, though there are better ways. It
only take seconds.

IME the Prism converter takes about as long as the programme it's
converting (1 hr for a 1 hr prog), although I do wind the bit rates on
the audio and video compressors up to maximum, which probably doesn't
help. I did say it was rather slow! What are these 'better ways',
please.

I don't have a Humax (yet ), so I've faced different problems, but
I'm guessing that using tsremux (if necessary) followed by VideoReDo
(maybe TVsuite version - all versions are available as free time-
limited demos) would be a far quicker route to DVD. Could be wrong -
depends what "issues" Humax files have.

I use VideoReDo TVSuite. It accepts Humax .ts files as input.

--
Peter Duncanson
(in uk.tech.digital-tv)

On Mon, 28 Sep 2009 09:11:45 +0100, "Zimmy" wrote:


"Alan" wrote in message
...
In message , Ivan
wrote



"The box's release date will be in the early part of 2010, with pricing
similar to Humax's current Freesat range."

Well 'if' that's true, than it all sounds very encouraging!

http://www.techradar.com/news/home-c...hd-receiver-ou
ted-634923

You will not be able to use it unless you can find someone to sell you a
HD aerial

...and make sure its an HD aerial that supports 1080p not just 720p ;-)

A "wideband" aerial is necessary for "widescreen" pictures, obviously.

An aerial made of gold would naturally be better than one made of alloy.
Unfortunately the necessary security cage round it to prevent theft
would seriously impede reception.


--
Peter Duncanson
(in uk.tech.digital-tv)

On Mon, 28 Sep 2009 08:55:28 GMT, Dave Farrance
wrote:

Where did I say that ext2/ext3 do not fragment?

"Apart from the fact that it usually needs defragmenting after a while
unlike ext2/ext3/ext4."

You said that it doesn't need defragmenting.
I'm sure you'll now try and nit-pick saying that it does fragment , but
doesn't need defragmenting , so I'll save you the bother.

Glad you said that because it's true. A fact is a nit-pick?

To some people who try and weasel their way out of their previous
incorrect statements, yes. A lot of people on here seem to spend their
lives trying to wriggle out of their previous incorrect comments, when
challenged.

Same goes for NTFS, in normal usage, actually.

So you are agreeing that filesystems fragment but don't need fragmenting,
which in turn implies that fragmentation doesn't matter.
The real question is: Why does this apparently apply to some filesystems
and not others and for what reasons?

On Mon, 28 Sep 2009 12:54:39 +0000, Paul Ratcliffe wrote:
So you are agreeing that filesystems fragment but don't need
fragmenting, which in turn implies that fragmentation doesn't matter.

It depends on the degree of fragmentation.

The fact is that ext2/ext3 filesystems do experience fragmentation but
there is no defragmentation tool supplied by default because the degree
of fragmentation which occurs is not sufficient to cause serious impairment.

The important factor is that these filesystems start losing significant
performance when filled to more than approximately 90% capacity.

As I mentioned in a followup correction, for the successor to ext3, namely
ext4, a defragmentation tool is going to be supplied.

The real question is: Why does this apparently apply to some filesystems
and not others and for what reasons?

Because of the design of the filesystem.

QUOTE

The Linux System Administrator Guide states, "Modern Linux filesystem(s)
keep fragmentation at a minimum by keeping all blocks in a file close
together, even if they can't be stored in consecutive sectors. Some
filesystems, like ext3, effectively allocate the free block that is
nearest to other blocks in a file. Therefore it is not necessary to
worry about fragmentation in a Linux system."

UNQUOTE

In article ,
Paul Ratcliffe wrote:

So you are agreeing that filesystems fragment but don't need fragmenting,
which in turn implies that fragmentation doesn't matter.
The real question is: Why does this apparently apply to some filesystems
and not others and for what reasons?

The consequences of fragmentation are different in different
filesystems. Some old filesystems required contiguous space for a
file or for certain types of file; fragmentation could mean that there
was a megabyte [sic] of space free but you couldn't create a megabyte
file. On most modern filesystems, it just means that more seeking
will be required so file access will be slower.

There are also intermediate situations, which are generally
obscure and unimportant.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Paul Ratcliffe wrote:

To some people who try and weasel their way out of their previous
incorrect statements, yes. A lot of people on here seem to spend their
lives trying to wriggle out of their previous incorrect comments, when
challenged.

After reading back up the thread, I have difficulty seeing which person
you're singling out and for what reason. Modern filesystems fragment, but
keep that fragmentation under control so that defragmentation isn't
necessary - especially if the hard-disk isn't filled to near-full, which
is no real problem with the disk sizes available lately.

Same goes for NTFS, in normal usage, actually.

So you are agreeing that filesystems fragment but don't need fragmenting,
which in turn implies that fragmentation doesn't matter.
The real question is: Why does this apparently apply to some filesystems
and not others and for what reasons?

Old operating systems benefited from defragmentation. For more details,
try Wikipedia.

Eric Shune wrote:
if the back up/copy to external USB is similar to the current Freesat HD box
then its pretty much useless. The file types are not a standard format.

The .ts files saved to a FAT32 or EXT3 USB drive work fine for me.
VLC playes them with no conversion.

I hope they add DLNA support to the freesat boxes - I'd buy a couple
more freesat receivers if they could all play back material from my HDR
over the network. In fact I'd probably buy at least one even if it
didn't include it's own receiver.

Arthur

Arthur wrote:
Eric Shune wrote:
if the back up/copy to external USB is similar to the current
Freesat HD box then its pretty much useless. The file types are not
a standard format.

The .ts files saved to a FAT32 or EXT3 USB drive work fine for me.
VLC playes them with no conversion.

I hope they add DLNA support to the freesat boxes - I'd buy a couple
more freesat receivers if they could all play back material from my
HDR over the network. In fact I'd probably buy at least one even if it
didn't include it's own receiver.



In some cases simply renaming them .MPEG seems to work OK.

J G Miller wrote:
On Mon, 28 Sep 2009 12:54:39 +0000, Paul Ratcliffe wrote:
So you are agreeing that filesystems fragment but don't need
fragmenting, which in turn implies that fragmentation doesn't matter.

It depends on the degree of fragmentation.

The fact is that ext2/ext3 filesystems do experience fragmentation but
there is no defragmentation tool supplied by default because the degree
of fragmentation which occurs is not sufficient to cause serious impairment.

The important factor is that these filesystems start losing significant
performance when filled to more than approximately 90% capacity.

As I mentioned in a followup correction, for the successor to ext3, namely
ext4, a defragmentation tool is going to be supplied.

The real question is: Why does this apparently apply to some filesystems
and not others and for what reasons?

Because of the design of the filesystem.

QUOTE

The Linux System Administrator Guide states, "Modern Linux filesystem(s)
keep fragmentation at a minimum by keeping all blocks in a file close
together, even if they can't be stored in consecutive sectors. Some
filesystems, like ext3, effectively allocate the free block that is
nearest to other blocks in a file. Therefore it is not necessary to
worry about fragmentation in a Linux system."

UNQUOTE

Interesting idea. Anyone done any heavy duty file access and can
confirm what happens?

It seems to me that the old classic of writing two files simultaneously,
so that they both grow at a similar rate, is going to give just as much
of a problem with this allocation strategy as it would on one that just
picked first available block. As would the other classic of writing
lots of small files, then deleting half of them at random. In fact I
can't see that this would help at all except in the case where you know
in advance how much data you're going to write, and tell the FS before
you write it.

Andy