Try leaving a little longer after switch on before interacting with the unit.

JayInBristol – 17 hours ago  » 

REPASSAC, do you think it could be related to the satellite dish, leads, connections etc? Just wondering. Or do you think it’s more likely to do with signal issues in different areas? Or…any other suggestions?

While aligning a dish some time ago the unit became quite unstable and rebooted twice. Quite understandable really, probably receiving rubbish for the EPG and other data.

Poor dish alignment can cause a range of problems, such a blocks on the picture. I doubt if your problem is connected with signal but if you want to check – try CBS action (On same satellite as the freesat transponder) and the main channels you watch.

Poor cable connections (or water ingression are more likely to give intermittent loss of signal.

I will be glad when the freesat transponder changes satellite and moves to a saterlite at the same position as all the others at 28.2E which is soonish, I think. This should also be good for us ex-pats where we can setup our dishes without using a compromise between settings for 28.2E and 28.5E.

I think the problem is down to freesat, hopefully it will just disappear soon.

It would be interesting to know how many of the lockups in this thread were complete (no response to any button or front panel) and just after startup.

While aligning a dish some time ago the unit became quite unstable and rebooted twice. Quite understandable really, probably receiving rubbish for the EPG and other data.

That’s not “understandable”. Understandable would be the unit reporting signal lost or similar, becoming unstable and crashing is a sign of poor software.

This whole problem is clearly triggered by something at the remote end but at the same time poor software (whoever it is written by) is responsible for the lock up.

REPASSAC – 3 hours ago  » 

I disagree. Catering for every theoretical situation is something that is called for in safety critical systems but not in a PVR, where the actual processing is mostly carried out by the chipset.

Even is safety critical systems, like flight control systems, do not cater for every possibility and a pilot and co-pilot is needed, just in case.

It’s not a matter of allowing for everything it’s making sure that external inputs not being correct can’t crash the code, I’ve been writing real time software for 35 years and I can assure you that if this happened to my software I would hold my hand up and admit it was a bug, I would be personally very disappointed at my software error. It’s called defensive programming and should be one of the main things any software engineer considers.

In the example you gave of realigning the dish this is not even a very unexpected set of circumstances with the signal input coming and going.

Even if it was a “chipset” locking up the controlling software should recognise this and deal with it. In this case it appears to be a thread that is stuck in an infinite loop of some kind (or waiting for an event that never occurs) which is the responsibility of the controlling software even if triggered by a chipset triggered by the top end.

The software does not appear to even have (well written) watchdog timers to deal with the locking up.

Obviously safety critical systems have higher standards than a PVR and the aim is to deal with every possibility with sensible default actions for something that is not understood. In many modern aircraft the electronics/computing is essential and the aircraft will not fly without them so the pilot is not there as a backup at all but there for when human control is needed.

Could it be anything to do with this pin 13 problem on the HDMI

http://www.amazon.co.uk/Lindy-HDMI-Less-Female-Adapter/dp/B00DL48KVI

damian – 2 minutes ago  » 

JamesB – 1 hour ago  » 

Offered the choice between a box with beautiful defensive code that filled its maker’s heart with pride, and a less expensive box which functioned satisfactorily for my purposes, I’d buy the latter.

they’re not mutually exclusive, well written code is less clunky, has a smaller footprint, runs faster, easier to maintain and passes through the testing process quicker, in theory better code is cheaper.

Ah yes, theory.

In practice, nobody can be sure of the end costs until it’s ready for market. Usually, the voices arguing for writing beautiful code aren’t the ones who carry the can if it ends up over budget and over the deadline.

Not I – not for invisible quality that doesn’t actually make a difference to me but has made some programmer a happy man. If the box is fit for purpose, I’m happy. If not, I’ll take it back.

Quality that makes a difference may be worth paying for. To me, it’s not worth paying money for theory.

Invariably is a big word. Give us an example?

damian – 2 hours ago  » 

……………….

The biggest problems for Humax seem to be hdcp and cec over hdmi which is an absolute nightmare and completely out of their control as are changes to freesat/showcase, youtube, iplayer, isp etc. etc. behind the scenes which again are completely out of Humax’s control, but Humax are forced to carry the can for it.

Invariably the less expensive option comes at a price later on

freesat also specified the UI. Control the EPG data (directly and indirectly with the broadcasters).

In many ways real time systems which update databases (are their any that don’t? Yes, I guess a PVR is one) are in a way simpler to handle. They run on machines with masses of memory, and when processing a stream of related data, can commit or rollback, something a PVR cannot.

In the example I gave the unit rebooted, I can’t know what rebooted the chipset or PVR code but perhaps that was by design to garbage data.

Edit: Damian – you must know full well that units at end of life should not go to landfill. Recycle.

think we are now a bit off topic.