Humax PVR-9200T - new software

"Jeff Layman" wrote in message
...
"Peter Duncanson" wrote in message
...
On Wed, 9 Jun 2010 19:56:34 +0100, "Jeff Layman"
wrote:

"Max Demian" wrote in message
...
A new version of software (1.00.23) is available for OTA download on
the
Humax PVR-9200T until 9am this Friday.

It fixes the problem of slow response to commands from the remote and
front panel which many people have experienced since the last major
retune
(30.09.09).

Also, the EPG is saved to HDD when you switch to standby, and reloads
it
in about half a minute when you switch out of standby, which is useful.
(Initial loading of the EPG takes quite a long time - an hour or so -
but
this doesn't matter as you only have to do it once unless the box
crashes.)

Anyone else get this notice at the end of the Update?

Notice
Expected Date 01:00:00, 01/01/2013 for 11:59:50
Network change notification; enhanced network
configuration; Version 2.0 Network change notification;
enhanced network configuration; Version 2.0
OK

I didn't notice anything like that.

Seems that Jim has seen it, and there has been one report of it in the
Digitalspy Humax forum. I wonder if it is area specific?

--

Jeff


The message appears at return from standby only the first time following
s/w update, Have not seen it since, I think it is irrellevent!

The message
from "Steve Thackery" contains these words:


"Brian Gaff" wrote in message
...

Why does it take so long tobuild the program guide though.

Bearing in mind it's on the hard disk, it could - to all intents and
purposes - be immediate. This is the case with my FoxSat HD-R.

I wonder if they are deliberately trickling it off the hard disk to reduce
processor and I/O loading, which suggests the processor is almost maxed out
even in normal running.

Just a theory (and not a very convincing one) - I can't think of any other
reason.

If, as I've seen mentioned elsewhere in this newsgroup, it's true about
the Humax and Topfiled PVRs both being based on a common reference
design, that theory will have a lot of basis in fact.

From what I've read about the problems of USB transfers with the Humax
and the relatively slow speed compared to the Topfield, my guess is that
the latter is blessed with twice as much cpu grunt as the former.

This would also explain why the symptoms due to DSO changes that Toppy
users have experienced have been far less extreme.

USB was initially concieved as a more flexible alternative to the
traditional RS232 (Com port) interface universally used on PCs.

Unfortunately, it was just sufficiently fast enough at the time (just
when P166MMX and better cpus were being fitted into entry level PC
boxes) to allow single high data rate devices, such as those infamous
"soft modems", to be inflicted onto computer users who weren't aware of
the technicalities of why USB was such a crap interface.

USB (versions 1 and 2, forget ver 3) relies on PIO control of the data
transfer, unlike other interfaces such as disk and network interfaces
which use DMA transfer modes.

PIO stands for "Programmed Input Output", meaning the CPU copies each
and every byte of data from the source device into its own internal
registers and then copies each and every byte thus stored to the
destination before repeating the cycle for the next 2 or 4 byte's worth.
This process is entirely processor intensive and is only acceptable when
a powerful enough CPU is employed (which, in the case of PCs and USB2,
happened about 6 or 7 years ago with the advent of GHz clocked CPUs).

DMA stands for "Direct Memory Access" which basically speaking, uses a
dedicated DMA controller chip to offload the transfer job from the main
CPU. In this case, the transfer request is merely a matter of supplying
the DMA controller with a source and destination address and the number
of bytes to be transferred before generating an interrupt to signal job
completion to the main cpu.

In this scenario, the DMA controller does all the 'donkeywork' whilst
the CPU simply issues the orders leaving it free to deal with other
tasks relatively unmolested by the data transfer (perhaps an interrupt
every 4096 bytes or multiples thereof).

Using the DMA controller to transfer data reduces the load on the CPU
by a good 2 or 3 orders of magnitude compared to the PIO method. Taking
the more conservative figure, a USB2 transfer job going flat out (about
40MB/s, in practice more like 30 to 33 MB/s) requiring a 1GHz clocked
CPU, could be done using DMA transfers with a 10MHz clocked CPU.

The CPU requirements in the Hummy and Toppy boxes for recording two TV
broadcast streams whilst watching a third simultaneously are
surprisingly modest compared to an 8 year old PC. The fact that the
Toppy struggles to achieve about one fifteenth the maximum practical
transfer speed of USB even in turbo mode (where the remote control
facility is suspended to minimize cpu workload) proves this.

Since the humax is even slower than the Toppy with regard to USB data
transfers[1], I think it's fair to say that it most probably has an even
slower cpu so it should come as no surprise that the Hummy suffered more
from the DSO changes and required so much more intelligent software
fixes (no microsoft styled 'bloatware' fixes here) to arrive at an
optimised compromise.

The really irritating thing about the "Reference Design" is the absence
of a network interface. Either it was simply absent altogether or else
it was one of those 'optional components' the manufacturers felt they
could do without. If it was the latter, then shame on both manufacturers
for not using it (and ditching the crap usb socket to make way for a
more useful ethernet socket). However, this has very little bearing on
the current software update to fix the latest DSO issues.

[1] For reference, on those rare occasions where I've resorted to using
the wife's christmas pressy to resolve 3 way scheduling conflicts, the
data transfers from the Toppy to my laptop via the usb interface (using
turbo mode) have taken about 15 minutes for an hour's worth of BBC
program content (back in the day when an hour's worth was just under
2GB). This approximates to about 2.25MB/s.

This is in stark contrast to the transfers between a 2004 vintage
desktop PC and an external USB hard disk drive which only required 1
minute to transfer the same amount of data (about 33MB/s).

If the Toppy had been equipped with a fast ethernet adapter (100Mbps)
it could have achieved a fourfold increase in transfer speed _without_
resorting to a "Turbo" mode to minimise the cpu load. In the case of the
Hummy, this would have eliminated the broken transfer syndrome the USB
suffered from and provided the same 8 to 9MB/s transfer speed gain.

In the case of the Toppy, there would also have been the opportunity to
install a media streaming TAP that wouldn't risk compromising the box's
basic functions as a PVR. One has to wonder just how old the reference
design is for it not to be a simple matter of fitting the appropriate
PHY chip and RJ45 socket to give it the much superior (in every way)
network interface and totally eliminate USB altogether.

"Max Demian" wrote in message
...
"Brian Gaff" wrote in message
...
Why does it take so long tobuild the program guide though.

Once it has been saved on HDD it only takes about half a minute after
coming out of standby. I don't call that long.

The time to build it initially (after the update) - about an hour or so -
is because it is doing the update at low priority so as to allow the
processor to respond to commands.

This doesn't make any sense.

Looking at my other box, each part of the EPG seems to be transmitted only
once every few minutes. If you selectively sample it you could
theoretically miss the same bit every time.

And in implementation terms. You don't need to "allow" the processor to
respond to commands. You implement a process of pre-emption so that if
there IS a command you stop updating the EPG to deal with it and if there
isn't you update the EPG as fast as the data stream allows.

tim

On Thu, 10 Jun 2010 11:12:12 GMT, smb wrote:

On Thu, 10 Jun 2010 11:58:41 +0100, Jeff Layman wrote:
Anyone else get this notice at the end of the Update?

Notice
Expected Date 01:00:00, 01/01/2013 for 11:59:50
Network change notification; enhanced network
configuration; Version 2.0 Network change notification;
enhanced network configuration; Version 2.0
OK

I didn't notice anything like that.

Seems that Jim has seen it, and there has been one report of it in the
Digitalspy Humax forum. I wonder if it is area specific?

I got a similar message too. Hannington transmitter.

Blackhill also.

On Thu, 10 Jun 2010 11:57:22 +0100, Steve Thackery wrote:

That will display a list of recorded programmes. Scroll to highlight the
programme you want to split, press Yellow (Edit), then select Trim.

You know, I've had a 9200 since they came out and - now that you mention
it - I remember doing that. But honestly, it's so long since I've done that
I'd completely forgotten all about it!

I tried it once and couldn't work out how to work it. I gave up with it
as the editing facilities were so bloody user hostile it wasn't worth
the aggro.... compared to a Panasonic on which you can do (what I presume
are) GoP accurate edits.

I use the Humax PVR9200T Media Controller by Andy Chappell:
http://www.enigma.eclipse.co.uk/huma...Controller.htm

Ah yes, that's the one I'm using. I have to say that I've never had a
problem transferring files over USB using that software, even before .23 was
released.

Again, I tried it a few times and it either gave up after a few MB of
transfer or crashed the PVR... usually both.
The best results used to be to tune it to 305 while doing a transfer.
Not that "best" was anything like "good". It was another exercise in
complete frustration.

On Thu, 10 Jun 2010 12:49:48 +0100, Max Demian wrote:

The one I use is to press Record while it's playing back, then Stop to stop
'playback record'. This produces a copy of part of a programmes with "(new)"
at the end of the filename. I then transfer all the bits of programme across
to a PC and use VLC to create Snapshots.

I found out by accident about that one. I never used it because the
recording of the playback always had glitches on the audio every few
seconds.

On Thu, 10 Jun 2010 11:47:35 +0100, MarkU wrote:

I'm on the Mendip transmitter. I got a different message about
DSO in my area in September 2011.

I got one about a date in the past. "Go figure" as they say.

Mendip went through DSO in April. However, I know there is final
re-tune required in Autumn next year to complete the switch over[1]
so it kind of makes sense.

[1] We still have 3 muxes at low power using 2k coding.

I've got a feeling it is two re-tunes. I think there's another
flamin' channel change as well as the switch to 8K on COM and
they don't happen at the same time.

On Thu, 10 Jun 2010 13:46:24 +0100, Paul D.Smith
wrote:

But if its now working, perhaps they've worked on the USB transfers too in
this release. Nice if they have.

It would've been nice if they'd told somebody what they'd fixed, instead
of us having to guess. I s'pose that's too complicated for the morons
at Humax though. Can't go round telling people things. Oh no, that would
never do.

On Wed, 9 Jun 2010 12:07:43 +0100, "Max Demian"
wrote:

A new version of software (1.00.23) is available for OTA download on the
Humax PVR-9200T until 9am this Friday.

It fixes the problem of slow response to commands from the remote and front
panel which many people have experienced since the last major retune
(30.09.09).

Also, the EPG is saved to HDD when you switch to standby, and reloads it in
about half a minute when you switch out of standby, which is useful.
(Initial loading of the EPG takes quite a long time - an hour or so - but
this doesn't matter as you only have to do it once unless the box crashes.)

One thing I have noticed is that if you want to start viewing a
recorded programme from this list you have to use 'Exit' rather than
'OK' which was the position with the older software. The more recent
software allowed you to use 'OK' which is more intuitive (or 'Exit').
I wonder why this was changed back.

Paul Ratcliffe wrote:
On Thu, 10 Jun 2010 11:47:35 +0100, MarkU wrote:

I'm on the Mendip transmitter. I got a different message about
DSO in my area in September 2011.

I got one about a date in the past. "Go figure" as they say.

Mendip went through DSO in April. However, I know there is final
re-tune required in Autumn next year to complete the switch over[1]
so it kind of makes sense.

[1] We still have 3 muxes at low power using 2k coding.

I've got a feeling it is two re-tunes. I think there's another
flamin' channel change as well as the switch to 8K on COM and
they don't happen at the same time.

From Page 3 :-

http://www.digitaluk.co.uk/transmitternetwork/tools__and__resources/almanac/installer_newsletters_transmitter_groups2009_pdfs/Installer_Newsletter_Mendip_1_month_out_FINAL.pdf

Arq A and B (aka COM 2 and 3) Increase power, change frequency, change to
64QAM, and presumably change to 8k too ? Q3 2011

Receiver retune required.

SDN (aka COM 1) changes to 64QAM and increases power Q1 2012

You might get away without the need for a retune ?

However, don't forget that those muppets at Ofcom, or is it the EU, or is the
ITU, who knows, have decided that UHF Ch 61 and 62 will be sold off after all,
but Ch 39 and 40 now won't, so PSB 1 at Mendip will have to move to IIRC Ch 51
from its present allocation of Ch 61 sometime in 2012 or 2013.

So more retuning chaos ahead.


--
Mark
Please replace invalid and invalid with gmx and net to reply.

www.paras.org.uk