Your are talking complete and utter nonsense.

Please stop before you embarrass yourself further.

The code I included is pseudo code that represents what is happening, not how it was written. Anyone with a grain of intelligence can see that it would take special action on the part of the programmer to deviate from a series of the type ni+1 = 2ni.


That's nothing more than purest gobbledegook.

It's a digital computer. By definition anything that it does must be representable by an algorithm.


This is also meaningless gibberish.

It doesn't matter how it was written. Eventually it will end up as machine code that the processor obeys.

And whatever method was used to write it, simplifying the algorithm is not going to increase memory usage.

Having established your true credentials in this area I rest my valise.

i.e. Someone who knows how to program a computer in both high level language and assembly code (and even machine code if necessary) and how a UI interfaces with the rest of the programming.


So you admit you were just stringing together some vaguely technical sounding terms that didn't actually mean anything?

Actually I will pick up the valise again as I forget to check some factoids with you. You are aware of course that all FF / RW speeds are very approximate? That these estimated speeds are greatly affected by the bit-rates used by different programmes on different channels? Of the way the bit-stream is formed in packets and stored on the PVR? Of how a statistical analysis of the bit stream could show up some curious artifacts depending on the disk cluster size chosen and how that affects the choice of notional FF/ RW speeds that is it reasonable to offer? Of course you are.

(I am also wary of anyone who claims to programme in assembler and machine code)

You were fortunate, then. That was not the experience that many of us had. Despite the musings to the contrary on this forum, it was a software, rather than a hardware, issue. There are very few, if any, reports of the issue, since the last OTA software update.

Foxsat HDR 'freezes' every day or two requiring power cycle to fix it

Humax HDR - I few things I wished were different

IF Humax can't / won't fix, should we go to Watchdog?

FOXSAT HDR really getting to me now

Humax Foxsat-HDR freeze up

Humax Crashes a lot

Of course I am. I've been doing this stuff for decades.

Trying to do accurate time calculations with anything that does not have a fixed correspondence between time and position in the datastream is, shall we say, interesting.

However, it isn't that much of a stretch as the PVR must necessarily supply frames to the TV at a fixed rate and FF is only a matter of omitting various proportions of those frames. FR is a little more demanding.

Anyway, that is nothing more than a red herring in this instance because Humax seem perfectly capable of handling ~2x ~4x ~16x ~32x and ~64x. If they can omit 3 frames in ever 4 and 15 frames in every 16 then there is no reason why they can't omit 7 frames in every 8.


Presumably because you don't know the difference.

If you really want to demonstrate the paucity of you knowledge, just ask and I'll explain.

Why? It's not that uncommon if one is writing device drivers, or such like.

Now you are guessing again.

Of course I know the difference between coding in assembler and machine code. It is a subtlety that is lost on most and not something worth willy-waving about. And I would not want to scare the horses by talking about what we used to do to live, running, online banking systems.

No, I'm not.

How else do you suppose that you would show the picture at a different speed?

This is the absolutely standard way to speed up any moving image on a digital computer.

Something of which I have first hand experience.


So why make a pointless comment: "I am also wary of anyone who claims to programme in assembly and machine code" which rather seems to indicate that you were more than a little clueless?

Because false immodesty is so unbecoming and a sign of desperation.

Just so you know - I have coded in high-level languages (on a modern PC), assembly (on a BBC Micro) and machine code (on a Spectrum when I was bored - obviously I didn't write much because poking REM statements character-by-character was not fun :P) - and I'm only 16. So I wouldn't be so hasty to judge


And I'm with Jepson on this one - even if they didn't make an algorithm and they just have a load of things like if(speed = x){ frames_to_skip = y; } - there's still not much of a reason why they would decide to miss out 8x. It wouldn't be any harder than the others. And if they did write an algorithm, it would be easier.

I have to agree with Graham on this one.Having purchased
my Foxsat HDR in 2008,I have rarely had a problem.
Occasionally a missed recording but they turn out to be down to the broadcaster and NOT Humax.My only real criticism of Humax is the inordinate amount of time they now take to release upgrades.

Without wishing to delve into the finer points of programming, which is way above my head, here is a little history.
Early versions of the 9200 model did have a X8 mode. Following pressure from various forums, I seem to remember that a higher speed was repeatedly requested and eventually introduced. For whatever reason X8 was dropped to accommodate this change. There was much discussion at the time, certainly on hummy.org. Unfortunately, the hummy.org archive is lost so I cannot verify the details or reasoning behind this logic, or lack of it.. There was probably some discussion on this forum at the time, if anyone cares enough to take the trouble to search.

As all subsequent Humax products have followed this pattern, I can only assume that the same module has been carried over, without any subsequent review. Of course, this may be not be the reason for the missing speed, but it sounds likely IMHO.

It would appear that the stability issue related to how the HDR was used. In my case I used to record radio a lot and I recollect posts indicating a particular problem in that area. I had the box in the attic and it got to the stage where I couldn't be ar&ed going up and down to reboot it. I gave it a final "chance" after the last firmware update and it has had no stability problems since.

That makes more sense I have never recorded radio on the hdr at all. The rare radio I record I just use a topfield 5800.

Interesting. I will be starting to record Radcliffe & Maconie from tomorrow on both the HDR and my Toppy to see which gives the easiest route to getting it on my MP3 player.

It depends on how easy it is to get a PC close to the Toppy as unlike the hdr it contains a device usb port. Other than that there should not be much difference.

I have a USB lead permanently connected to the Toppy to run to the laptop when needed. It is more of a hassle converting the .rec format to MP3 from my previous experience.

It's been a while but if I remember right I used videoredo to edit the footage. Loaded the mpeg2 programme stream file output from videoredo into Premiere Pro and exported the audio as a .wav (it was going to CD). There must be loads of other ways.

vlcplayer and tsmuxergui spring to mind.

Same here. The only missed recordings I have ever had were caused by power cuts. Such a shame that it took them nearly 2 and a half years to fix it although technically still not "officially" fixed as it is still in Beta.


Yes - I also recollect various postings about problems when recording a radio channel.