Initial black screen/error at switch on

...
So no, I think there is only one decoder (ie module which decodes the M2TS into separate PCM video and audio streams).
...
Well, one for video and one for audio.

The 7405 SoC has serial inputs (PKTn, each comprising Data, Clock, Sync, Valid, Error) through which the demodulated DVB multiplex streams from the CXD2820R tuner demodulators must be connected. I suppose that 2 of the 6 available PKT inputs are used, 1 per demodulator. The demodulators in turn are managed by I²C, presumably using the SoC's BSC I²C test interface.

The streams are received, buffered, demuliplexed and (if necessary) decrypted by the SoC's Data Transport module according to the selected programs (PIDs), passed to the Video and Audio Decoder modules, and then to be displayed/recorded/RF modulated. The part of the installed memory that isn't visible to Linux is presumably being used to stage this process.

As to the fault in question, if the fault is affecting both tuner/demodulator paths, the SoC internals would seem to be fingered, with two or more separate bad ball connections to the chip as a lesser possibility. Or just possibly the PSU is unstable while warming up, sufficiently to cause the tuner/demodulator paths (eg) to fail without crashing the SoC; perhaps there's a separate rail for the tuners that's slow to come up?

Clearly scheduling two recordings to start simultaneously on different muxes will show if both tuner/demodulators are affected.
 
Last edited:
As the signal detection reports OK (even during the fault symptoms),
How do we know that? OP has only given data without annotating it exactly when it was taken. Can OP actually invoke and see the menus during the 'warm up' period?
 
So if I left the box on all the times recordings would be ok but timed recordings are the problem because the machine is cold starting.
I don't understand the sense in that. Do you not realise that timed recordings don't need the unit to be in standby?
 
So leave the box permanently on
There are many discussions on the advantages of 24x7 running, though a daily time switch restart is useful to protect against hangs (especially while away from home)

Do you use Accurate Recording? With AR the box should switch itself on over 10 minutes ahead of the scheduled recording start so I would have expected it to have 'warmed up' sufficiently before starting to actually record.
I will not leave it on for reasons of safety and my electricity bill.

I think so, can't check now as I am recording so can't access that menu. Does this not just switch on momentarily? As a workaround I have tried manually adjusting the start time, however this has sometimes affected up the end times - don't know if this is another glitch or related to the other one. This also has the annoyance of labelling the programme with the previous show. I am testing if a sacrificial recording might be another workaround - record the preceding show to allow a warm up.
 
Hmm. I'm into "best guesses" here, but the output of each tuner is a data stream containing multiple services (each of which is a container for multiple individual data streams... so the tuner output is a "super-container" maybe?). Each super-stream has to come into the SoC separately and demuxed into services separately, and then up to three services selected and passed on for further processing (all of this going on in hardware).

However, at that point the service streams are M2TS - ready for dumping to disk for recording or TSR. No further decoding is required until presentation (output by HDMI or SCART/Phono).

So no, I think there is only one decoder (ie module which decodes the M2TS into separate PCM video and audio streams).


It appears the data is therefore faulty before it gets to the disk, and therefore before it gets to a decoder. Therefore my statement

was a bit lax. What I meant was "somewhere within the datapath after the signal extraction and before the HDMI output".

As the signal detection reports OK (even during the fault symptoms), there's clearly a physical fault - and as the fault ceases to manifest after a "warm up" period the most likely explanation is that it is in some way related to heat and the work-around (for the time being) is not to let it cool down. But that is only a work-around, and it could cease to be effective at any time.

Can we pin this fault down any further, and is there any point? I believe so (this is how I used to earn my living in the development labs, but I had access to circuit diagrams!).

The signal strength figure has to come from the tuner front-end, so there has to be a live feed of that value from the tuner module to the SoC. Is that an analogue voltage on a wire (one for each tuner), or a response to a query on a data bus such as I²C or JTAG? I don't know, but the tuners have to be sent commands for tuning, so my guess is that would be done by serial bus, and status is probably reported the same way. The quality figure is a measure of how much error correction is going on after the demodulator. Where is the error correction? It could be in the SoC, but my guess is that the tuner modules also do this and are therefore also the source of the quality stats.

The typical heat-related fault is an intermittent circuit break which opens when the parts expand or contract. If I can pin this fault down to a PCB pad, it might be possible to repair by resoldering a pin. It seems to me the only hope of this is if the fault is on the input to the SoC from one tuner only, in which case we should see differences in performance between the two tuners (and the fault could be in the tuner itself). Otherwise the fault is within the SoC, and therefore irreparable.

Things to test (for more data):
  • Individual tuner tests available from the hidden menu - see Things Every... (click) section 9.
  • Record two programmes (from different muxes) at the same time.
If the individual tuner tests show no difference between the tuners, or the fault manifests on both simultaneous recordings despite them coming from separate multiplexes, I think we're stuffed.

Meanwhile, I strongly advise not subjecting the unit to physical shock. If the problem is something come adrift, shock could make it better... or permanent.
Tuner tests are identical for both tuners and the same as my first test.
 
How do we know that? OP has only given data without annotating it exactly when it was taken. Can OP actually invoke and see the menus during the 'warm up' period?
Test done immediately after switch on. I can see all menus and have full functionality apart from the fault.
 
I will not leave it on for reasons of safety and my electricity bill.
That's your prerogative. However, I trade safety and cost for convenience - and your convenience would be much greater than mine.

Just how much is safety compromised by 24/7? There has not been even a single report of a HDR-FOX failing unsafely (eg catching alight).

How much does 24/7 cost? Well. the max power consumption is quoted as 28W, that's 245kWh/year, and at 13p/unit = £31.85 PA.

What you might not appreciate is that if your problem is caused by a broken connection, which mysteriously fixes itself with heat (not impossible, but it's usually the other way around), the problem will deteriorate over the longer term, exacerbated by thermal cycling, and potentially become permanent. If you wish to preserve your HDR-FOX for the longest possible time... don't turn it off!

Tuner tests are identical for both tuners
So, what about the dual recording test?
 
I will not leave it on for reasons of safety and my electricity bill.

I think so, can't check now as I am recording so can't access that menu. Does this not just switch on momentarily? As a workaround I have tried manually adjusting the start time, however this has sometimes affected up the end times - don't know if this is another glitch or related to the other one. This also has the annoyance of labelling the programme with the previous show. I am testing if a sacrificial recording might be another workaround - record the preceding show to allow a warm up.
Modern disks are designed for 24x7 operation and there are no known reports of dangerous overheating of Humax units.
You may have seen mentions of disk overheating on other forum threads - this is related to disk performance and not a safety concern

However if you don't wish to leave the box on 24x7 you can set a Reminder for the programme before or a repeating Reminder for the whole period that covers your normal recording and viewing times. Reminders ensure the box is fully awake without actually making a recording.

If you have the customised firmware installed you can use the Sysmon package to monitor the disk temperature and the fan package to maintain a more constant temperature than the Humax standard firmware, It might be interesting to see what temperature your system is running at when it is failing and when it is running correctly.
 
If it is the case that the tuners and the OS and menus are working OK during the fault period, and considering that an IC properly connected to a PCB is quite unlikely to fail internally except from extreme mechanical, thermal or electrical stress, it might be worth considering other failure modes apart from the SoC's internals.

The demodulators and their connections are probably ruled out because it seems that each tuner is controlled by the demodulator, except for the demodulator -> SoC connections.

The SoC uses staging RAM for AV processing and a transient failure in this area might lead to the observed symptoms: either the chips themselves (but the proviso above applies), or their connections, or a PCB trace, or the connections at the SoC.

That's about the last point where a fault outside the SoC could affect both recordings and viewing similarly, as observed. A recording is plucked from the SoC's AV chain by the Humax software running under Linux and fed into a disk file.
 
It hardly matters where the fault is except to decide whether there's a work-around or if it can be fixed. Both tuners seem to work, so there is no mileage in replacing a tuner can. If the fault is a cracked solder joint, reflowing it could solve the problem but it's a specialist job (depending where the crack is). If it's a PCB track that's cracked, again it could be repairable with sufficient resources. It's all a question of how far the OP wants to take it.

If it were me, and it was just one of my units, I would retire it (and attempt repair off-line, if I found the time). If it were my last unit, I would be doing everything I could to preserve it until such time as I sourced another.
 
Last edited:
Back
Top