• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

HDR-Fox T2 Stability

martinr

Member
My main HDR-Fox T2 is relatively stable: I can access iPlayer in the Humax portal without problem, and a crash is very rare. In contrast, my spare HDR-Fox T2 seems quite “fragile” in that at times it will crash almost if you look at it. And certainly, accessing iPlayer via the portal will, 9 times out of 10, crash it. Generally, I can restore stability using the system flush firmware and then reinstalling the CFW.

The only obvious difference between these boxes is that my stable box has the 2 aerial sockets one above the other, and the unstacle, spare box has them side by side.

I wonder is this outward physical difference pissibly indicative of different internal hardware components that might explain differences in stability?

(Using a Fluke oscilloscope in record mode, I have ruled out the power supply of the spare T2 as a cause of its occasional “fragility”.)
 
It may be just coincidence. A sample size of 1 horizontal and 1 vertical isn't very large.

If it were indicative then other things to consider include that horizontal socket units are older than vertical socket units and therefor older PSBs, older components, older soldering, and may tend to have had more usage.
Also the fan appears to have been assembled blowing out on the earlier units but blowing in with the newer vertical units and horizontal units. This would impact the temperature of some components.
 
It's an interesting observation. My explanation for at least some of the crashes is that buggy code comes into play when untested situations arise - eg network errors. This correlates with my impression that a unit not connected to a network at all crashes far less than a unit that is.

As a hypothesis, this rules out the difference between the original units and the revised units, since they run the same code.

Further data required.
 
I wonder is this outward physical difference pissibly indicative of different internal hardware components that might explain differences in stability?
As a hypothesis, this rules out the difference between the original units and the revised units, since they run the same code.
Am I missing something? Couldn't both of you be right? Different hardware with the same firmware could still lead to different behaviour when the unexpected happens. For example (with no evidence for this), perhaps older machines have a network chip that craps out disgracefully when confused causing the firmware to bomb. Newer network chips might fail in a different way that doesn't take the firmware with it.
 
It's an interesting observation. My explanation for at least some of the crashes is that buggy code comes into play when untested situations arise - eg network errors. This correlates with my impression that a unit not connected to a network at all crashes far less than a unit that is.

As a hypothesis, this rules out the difference between the original units and the revised units, since they run the same code.

Further data required.


Based on your comments about the network in an earlier thread, I changed the ethernet cables for Cat 7 ones, and I also tried it disconnected from the network.

Hopefully, the spare box will never be needed. In the meantime, I’ve now got more food for thought and will persevere to get a better idea of any patterns of behaviour.
 
Am I missing something? Couldn't both of you be right? Different hardware with the same firmware could still lead to different behaviour when the unexpected happens. For example (with no evidence for this), perhaps older machines have a network chip that craps out disgracefully when confused causing the firmware to bomb. Newer network chips might fail in a different way that doesn't take the firmware with it.
I'm not aware the core electronics in the updated units has changed.
 
Strange thing on my spare, temperamental HDR-Fox T2: yesterday I ran a system flush using the System Flush Update File in the Firmware Downloads. On restart, the wizard asked for a coupke of settings and then ran the channel search. I then entered the IP address in my browser and to my surprise I got the full webui, and as far as I could tell, all my installed packages were in place. I ran the flush again today, thinking I had done something wrong but exactly the same thing happened: the setup wizard to start with followed by a channel search, and yet I log into the full webui of the CFW and see all installed packages in place, all sertings as they were before the system flush, except I see that Content Sharing in boot settings is now Off. Otherwise, it’s as if I never ran the flush.

It’s genuine and definitely not old beowser cache being displayed.

I’m sure when I previously used the system flush, it wiped everything and I then had to re-install the CFW afresh. Now, I’m looking at the full CFW in the full webui immediately after the flush.

Any ideas what I’m doing wrong or overlooking?
 
From af123’s reply to a previous post:


I would install the system flush update to completely reset the internal flash memory.. you'll lose all of your settings but it should fix any corruption in the JFFS2 filesystem.
https://wiki.hummy.tv/wiki/Firmware_Downloads

And the notes on the CFW download page:

“Install as standard firmware update to perform a full system flush and reset. This is designed to assist recovery from crash/reboot loops and to clear everything out after running RMA mode.”

I thought System Flush was “bog brush” flush.

So, I should run RMA mode and then system flush and then reinstall either stock firmware or CFW for bog brush flush?
 
Last edited:
So, I should run RMA mode and then system flush and then reinstall either stock firmware or CFW for bog brush flush?

For cleaning all traces of the CFW:
- Put into RMA mode, reboot, install standard firmware, install system flush.

For resetting CFW completely:
- Reset CFW (from Diagnostics screen)

Optionally, if you want, install system flush to reformat the flash areas in conjunction with doing a CFW reset, or without but in that case all of the CFW files on the hard disk are not touched, but you should run the fix-flash-packages diagnostic to replace the now missing bits in flash.

There should never be a need to use RMA mode unless you're trying to remove all traces of the CFW before sending the unit back or on to somebody else but unfortunately it's often suggested as a way of resetting things. RMA is basically CFW reset + hold-down afterwards.
 
For cleaning all traces of the CFW:
- Put into RMA mode, reboot, install standard firmware, install system flush.

For resetting CFW completely:
- Reset CFW (from Diagnostics screen)

Optionally, if you want, install system flush to reformat the flash areas in conjunction with doing a CFW reset, or without but in that case all of the CFW files on the hard disk are not touched, but you should run the fix-flash-packages diagnostic to replace the now missing bits in flash.

There should never be a need to use RMA mode unless you're trying to remove all traces of the CFW before sending the unit back or on to somebody else but unfortunately it's often suggested as a way of resetting things. RMA is basically CFW reset + hold-down afterwards.


Sincere thanks.
 
Found the source of the instability on my spare HDR-Fox T2, which caused it to freeze/lock up every couple of hours.

I replaced the heatsink
6A5421D5-109B-45FF-BD35-29308ECF4772.jpeg



With a home-made one

E0BC9168-B103-48AB-80CB-026A20EE241F.jpeg




And comparing my spare box with my main HDR-Fox T2, it’s quite clear there are significant differences on the motherboard berween the older design (antenna sockets side by side) and the newer one, which my main box is (sockets one above the other):


2416C1EB-CB77-4D26-90AF-6E52FC1E8F8B.jpeg



The spare HDR-Fox T2 is now stable (fan on 100% of the time) but if the temperature of the heatsink hits 50C (eg by playing a heat gun on it to simulate a hot day or enclosed space), the box will freeze.


I imagine age has taken its toll and the box can no longer cope with a system temp of 50C: my newer, main box does not freeze at 50C; hopefully, I’ll never need to fall back on this older, spare box, but the crashes were solved by a complete “bog brush” clean and CFW reinstall, and the freezes/lock-ups solved by a bigger heatsink and keeping the fan on all the time. Even iPlayer in the Humax Portal is now stable.
 
Found the source of the instability on my spare HDR-Fox T2, which caused it to freeze/lock up every couple of hours.

I replaced the heatsink ... With a home-made one
[beefy 2mm aluminium heatsink]
...
Had you tried applying the new thermal compound to the original heatsink?

Perhaps the original stuff had just rotted away from the chip-heatsink joint due to thermal cycling.
 
Had you tried applying the new thermal compound to the original heatsink?

Perhaps the original stuff had just rotted away from the chip-heatsink joint due to thermal cycling.


Good point. The original heatsink was very tinny and flimsy. More importantly, it was stuck to the cpu (I’m guessing the chip is the cpu) with self-adhesive tape and not thermal paste. The heatsink needed a great deal of persuasion to release from the chip; so much so that the force needed to prise it off, bent it out of shape even if I had any intention of re-using it, I couldn’t realistically have done so. I did use thermal paste (ZF) on the new heat sink. And, though it’s hard to see, I cut out a 10mm x 8mm piece in the middle for the slightly raised bit on the chip, and then put a blob of paste on it and pressed it in place. Without it, that central part gets quite hot.
 
Last edited:
Without it, that central part gets quite hot.
The central part is the die or chip and that's where the heat is dissipated. So I'd expect it's now actually running hotter than with the stock heatsink - did you do before and after measurements?

FWIW I suspect the problem is actually a broken solder joint under the BGA package.
 
The central part is the die or chip and that's where the heat is dissipated. So I'd expect it's now actually running hotter than with the stock heatsink - did you do before and after measurements?

FWIW I suspect the problem is actually a broken solder joint under the BGA package.


It’s running cooler than before; I have a Fluke infrared thermometer and it showed that the top left hand corner was the hottest (stood facing the front panel) at least as hot as the central part. But the proof is in the puddung: it doesn’t freeze any more.

I did tap around the motherboard looking for dry joints. I feel as if I’m treating the symptom rather than the cause, so I’m interested in your theory. What is the “BGA package”; where do I find it, and would the broken solder joint be visible? I presume it would be on the underside of the board?
 
BGA - ball grid array

https://en.wikipedia.org/wiki/Ball_grid_array

The chip connections are underneath the package, rather than round the sides, allowing greater connection density. Downside is that they can be very difficult to troubleshoot since you can't get scope probes on them, and if you get a dodgy joint they require specialist kit to reflow the solder connections by localised heating of the chip from both sides of the board. Pretty much beyond the capabilities of the home repairer.
 
Can you quantify, just out of interest?

From tempmon, I would see a steady-state temperature of around 42 whereas now I see 33/34C. Because of the wings of the heatsink, I couldn’t get the thermometer gun in close enough on the old heat sink to get a spot reading on the centre only, but it was hot enough for me not to want to keep my finger there for too long, whereas now the centre feels no warmer than the rest of the heatsink. I see around 35C with the thermometer gun for the heatsink, but again I can’t get close enough to the centre to be certain I’m measuring only the centre and not including the surrounding area of the heatsink.
 
Back
Top