A Sky, cable and digital tv forum. Digital TV Banter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » Digital TV Banter forum » Digital TV Newsgroups » uk.tech.digital-tv (Digital TV - General)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

uk.tech.digital-tv (Digital TV - General) (uk.tech.digital-tv) Discussion of all matters technical in origin related to the reception of digital television transmissions, be they via satellite, terrestrial or cable. Advertising is forbidden, with no exceptions.

Slow Humax PVR 9200



 
 
Thread Tools Display Modes
  #21  
Old March 25th 10, 10:11 PM posted to uk.tech.digital-tv
Jim
external usenet poster
 
Posts: 70
Default Slow Humax PVR 9200


"Ivan" wrote in message
...



Once again (in case my follow-up post didn't show up) thanks to everyone
for the prompt replies, 'the boy' rang me this evening to say that he has
followed the suggestion of simply deleting (about 20) channels he never
uses and says that everything now appears back to normal..


That is what i had done when i got my one back from Humax it's still slow
sometimes and does freeze as well but much less now i have wiped some of the
channels


Ads
  #22  
Old March 25th 10, 10:17 PM posted to uk.tech.digital-tv
Peter Duncanson
external usenet poster
 
Posts: 4,272
Default Slow Humax PVR 9200

On Thu, 25 Mar 2010 22:41:58 -0000, "Ivan"
wrote:



"Peter Duncanson" wrote in message
.. .
On Thu, 25 Mar 2010 22:12:59 +0000, Paul_Jones
wrote:

On Thu, 25 Mar 2010 20:59:41 +0000, Scott
wrote:

They have been promising an update for a long time. How difficult is
to update the software? Does anyone know?

I have the same here. Remote response was slow before DSO but is now
unusable. Nothing helps (not resetting or removing and adding channels
manually).
IMO Humax are now officially crap.
Going to swap mine for a Topfield or similar. I know they have problems
too but they seem to be a bit more up-front, honest and proactive about
resolving them.
The way Humax have delayed getting the 9200 update out is unforgivable!


It would be even more unforgiveable if Humax released an update that
still contained major flaws from the previous version!

As a Humax PVR-9200T owner I would like to have the update as soon as
possible.

As a retired computer programmer I know that sometimes there are nasty
bugs in software that can be absolute pigs to fix.



Let's hope that that it is due to software and not hardware, i.e. processing
power or memory related, similar to what allegedly killed off the 250,000
Daewoo Labgear STBs with the Split Nit problem.

I don't know the internal details of the boxes but I've been
increasingly wondering whether hardware limitations might be making a
cure difficult or impossible.

--
Peter Duncanson
(in uk.tech.digital-tv)
  #23  
Old March 25th 10, 11:50 PM posted to uk.tech.digital-tv
Steve Thackery[_2_]
external usenet poster
 
Posts: 2,552
Default Slow Humax PVR 9200


"Peter Duncanson" wrote in message
...

I don't know the internal details of the boxes but I've been
increasingly wondering whether hardware limitations might be making a
cure difficult or impossible.


The behaviour shown is quite typical of a system which is running out of
processing power - the very long delays in responding to user inputs (often
with the responses clustering together in bursts); the lock-ups which often
arise when message queues and stacks exceed their design limits.

To be honest, though, if that were the case I would have expected the 9200T
to have been showing *some* signs of processor shortfall before now. On the
contrary, it seems reasonably punchy compared with many of its competitors.
This makes me suspect that there may be a very sub-optimal, processor-hungry
algorithm hidden away in the code which has only recently come to light.

On the other hand, I did wonder if it might be a hardware shortcoming, but
not in the processor; rather, in the supporting signal processing chippery.

If it should turn out to be a hardware limitation and we're stuffed, I would
like Humax to come clean as soon as possible so I can get on with looking
for an alternative.

My instinct, though, is that it is something fixable in software (especially
as the Toppy shares the same reference design and I haven't heard Toppy
owners complaining here).

SteveT

  #24  
Old March 26th 10, 12:04 AM posted to uk.tech.digital-tv
Steve Thackery[_2_]
external usenet poster
 
Posts: 2,552
Default Slow Humax PVR 9200


"Peter Duncanson" wrote in message
...

Yes, but because the total information to be carried is divided into
8000 streams rather than 2000 the amount to be carried by each
sub-carrier is reduced to a quarter (8000/2000).[1]

This and the material it links to have much more information:
http://en.wikipedia.org/wiki/OFDM


Many thanks for that link.

I've read it, but I'm still unclear: what is the advantage of 8k over 2k?
It seems like the overall capacity would be about the same.

Sorry to be thick.

SteveT

  #25  
Old March 26th 10, 07:59 AM posted to uk.tech.digital-tv
Scott
external usenet poster
 
Posts: 867
Default Slow Humax PVR 9200

On Thu, 25 Mar 2010 22:16:05 +0000, Peter Duncanson
wrote:

On Thu, 25 Mar 2010 20:59:41 +0000, Scott
wrote:

On Thu, 25 Mar 2010 14:22:04 -0000, "Ivan"
wrote:

When I upgraded my Humax PVR 9200 (to a PVR 9300) I passed it on to my son
and it has worked fine until a couple of days before the DSO here in the
West region, since when it has now become so slow as to be virtually
unusable, I appreciate that this isn't a new or unknown problem with this
model, however does anyone know if there is a fix now available, or if there
will be one arriving in the not too distant future. TIA


They have been promising an update for a long time. How difficult is
to update the software? Does anyone know?


It has been reported that the software is being tested by a few
customers. It is not yet ready for general release.

I suspect that the problems that people have reported cannot be
reproduced in the laboratory.


Do you think more resource would speed up the task? Are Humax giving
this problem the priority it deserves? It's all very well to refer to
old boxes but what about reputational damage to the company? What is
the cost of that in the longer term. I would extricate the digit if I
were them.
  #26  
Old March 26th 10, 09:34 AM posted to uk.tech.digital-tv
Peter Duncanson
external usenet poster
 
Posts: 4,272
Default Slow Humax PVR 9200

On Fri, 26 Mar 2010 00:50:19 -0000, "Steve Thackery"
wrote:


"Peter Duncanson" wrote in message
.. .

I don't know the internal details of the boxes but I've been
increasingly wondering whether hardware limitations might be making a
cure difficult or impossible.


The behaviour shown is quite typical of a system which is running out of
processing power - the very long delays in responding to user inputs (often
with the responses clustering together in bursts); the lock-ups which often
arise when message queues and stacks exceed their design limits.

To be honest, though, if that were the case I would have expected the 9200T
to have been showing *some* signs of processor shortfall before now. On the
contrary, it seems reasonably punchy compared with many of its competitors.
This makes me suspect that there may be a very sub-optimal, processor-hungry
algorithm hidden away in the code which has only recently come to light.


On the other hand the behaviour is suggestive of memory limitations. An
apparently lightweight[1] action can be held up for a long time simply
waiting for memory to become available.

[1] Lightweight in the sense of not being processor- or memory-hungry.

--
Peter Duncanson
(in uk.tech.digital-tv)
  #27  
Old March 26th 10, 09:46 AM posted to uk.tech.digital-tv
Peter Duncanson
external usenet poster
 
Posts: 4,272
Default Slow Humax PVR 9200

On Fri, 26 Mar 2010 01:04:46 -0000, "Steve Thackery"
wrote:


"Peter Duncanson" wrote in message
.. .

Yes, but because the total information to be carried is divided into
8000 streams rather than 2000 the amount to be carried by each
sub-carrier is reduced to a quarter (8000/2000).[1]


That might be better expressed as 2000/8000. :-)

This and the material it links to have much more information:
http://en.wikipedia.org/wiki/OFDM


Many thanks for that link.

I've read it, but I'm still unclear: what is the advantage of 8k over 2k?
It seems like the overall capacity would be about the same.

Sorry to be thick.


I'm just as thick.

The overall capacity is similar but the performance under adverse
conditions is better.

Maybe a clued-up person could give us a mini-lecture on the topic.


--
Peter Duncanson
(in uk.tech.digital-tv)
  #28  
Old March 26th 10, 09:55 AM posted to uk.tech.digital-tv
Scott
external usenet poster
 
Posts: 867
Default Slow Humax PVR 9200

On Fri, 26 Mar 2010 10:34:11 +0000, Peter Duncanson
wrote:

On Fri, 26 Mar 2010 00:50:19 -0000, "Steve Thackery"
wrote:


"Peter Duncanson" wrote in message
. ..

I don't know the internal details of the boxes but I've been
increasingly wondering whether hardware limitations might be making a
cure difficult or impossible.


The behaviour shown is quite typical of a system which is running out of
processing power - the very long delays in responding to user inputs (often
with the responses clustering together in bursts); the lock-ups which often
arise when message queues and stacks exceed their design limits.

To be honest, though, if that were the case I would have expected the 9200T
to have been showing *some* signs of processor shortfall before now. On the
contrary, it seems reasonably punchy compared with many of its competitors.
This makes me suspect that there may be a very sub-optimal, processor-hungry
algorithm hidden away in the code which has only recently come to light.


On the other hand the behaviour is suggestive of memory limitations. An
apparently lightweight[1] action can be held up for a long time simply
waiting for memory to become available.

[1] Lightweight in the sense of not being processor- or memory-hungry.


Do you think there may be a prospect of adding memory then? Is it
standard memory modules you could go out and buy?
  #29  
Old March 26th 10, 10:37 AM posted to uk.tech.digital-tv
Peter Duncanson
external usenet poster
 
Posts: 4,272
Default Slow Humax PVR 9200

On Fri, 26 Mar 2010 10:55:02 +0000, Scott
wrote:

On Fri, 26 Mar 2010 10:34:11 +0000, Peter Duncanson
wrote:

On Fri, 26 Mar 2010 00:50:19 -0000, "Steve Thackery"
wrote:


"Peter Duncanson" wrote in message
...

I don't know the internal details of the boxes but I've been
increasingly wondering whether hardware limitations might be making a
cure difficult or impossible.

The behaviour shown is quite typical of a system which is running out of
processing power - the very long delays in responding to user inputs (often
with the responses clustering together in bursts); the lock-ups which often
arise when message queues and stacks exceed their design limits.

To be honest, though, if that were the case I would have expected the 9200T
to have been showing *some* signs of processor shortfall before now. On the
contrary, it seems reasonably punchy compared with many of its competitors.
This makes me suspect that there may be a very sub-optimal, processor-hungry
algorithm hidden away in the code which has only recently come to light.


On the other hand the behaviour is suggestive of memory limitations. An
apparently lightweight[1] action can be held up for a long time simply
waiting for memory to become available.

[1] Lightweight in the sense of not being processor- or memory-hungry.


Do you think there may be a prospect of adding memory then? Is it
standard memory modules you could go out and buy?


I don't know. I haven't opened the box to look.


--
Peter Duncanson
(in uk.tech.digital-tv)
  #30  
Old March 26th 10, 12:00 PM posted to uk.tech.digital-tv
Scott
external usenet poster
 
Posts: 867
Default Slow Humax PVR 9200

On Fri, 26 Mar 2010 11:37:13 +0000, Peter Duncanson
wrote:

On Fri, 26 Mar 2010 10:55:02 +0000, Scott
wrote:

On Fri, 26 Mar 2010 10:34:11 +0000, Peter Duncanson
wrote:

On Fri, 26 Mar 2010 00:50:19 -0000, "Steve Thackery"
wrote:


"Peter Duncanson" wrote in message
m...

I don't know the internal details of the boxes but I've been
increasingly wondering whether hardware limitations might be making a
cure difficult or impossible.

The behaviour shown is quite typical of a system which is running out of
processing power - the very long delays in responding to user inputs (often
with the responses clustering together in bursts); the lock-ups which often
arise when message queues and stacks exceed their design limits.

To be honest, though, if that were the case I would have expected the 9200T
to have been showing *some* signs of processor shortfall before now. On the
contrary, it seems reasonably punchy compared with many of its competitors.
This makes me suspect that there may be a very sub-optimal, processor-hungry
algorithm hidden away in the code which has only recently come to light.

On the other hand the behaviour is suggestive of memory limitations. An
apparently lightweight[1] action can be held up for a long time simply
waiting for memory to become available.

[1] Lightweight in the sense of not being processor- or memory-hungry.


Do you think there may be a prospect of adding memory then? Is it
standard memory modules you could go out and buy?


I don't know. I haven't opened the box to look.


Is it necessary to open the box to look? Is there anyone out there
who knows the spec of this unit and can tell us (1) whether the memory
is upgradeable and (2) whether the software and hardware can support
extra memory?

When I was a boy I was always told that the most effective way to
improve the performance of any computer was to add memory.
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 12:12 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.SEO by vBSEO 2.4.0
Copyright 2004-2018 Digital TV Banter.
The comments are property of their posters.