HDR-FOX T2 Green screen of death?

X

xyz321

Well-Known Member
I've just had the green screen of death. I was watching live and then tried to start playing an HD program which immediately brought up the green screen of death. The box was completely unresponsive to any remote or front panel functions. I could not telnet into the box. After switching off at the back I now find the box is completely dead - no front panel LED.
 
That sounds pretty terminal :(

If you are happy opening up, have a sniff around (literally) - a blown component often leaves a smell. Look for any fuses as well.
 
No blown fuses or any obvious blown components but the bridge rectifier seems to have lost some of its diodes. It remains to be seen whether this is the primary failure or just collateral damage.
 
My mistake, the bridge rectifier was fine. Anyway after much probing around, it suddenly decided to start working again. :)

All very strange.
 
Not so strange. I've not looked inside one yet - does it have a wound transformer? Sometimes they are fitted with self-resetting thermal fuses. Sometimes they are fitted with non-resettable thermal fuses (bad news).
 
It does have a wound transformer as part of a SMPS arrangement. The fuse is a 3.15A antisurge type in a radial PCB mount package - probably something like this (I haven't checked the physical dimensions).

After several hours without power I would have thought that any resettable fuses would have had plenty of time to reset.

Edit: I should also add that the problem recording, which appeared to start my green screen problem, now plays back fine.
 
The thermal fuse I have in mind would be buried inside the transformer windings, usually inaccessible.

Perhaps we should split the topic at post #32 and give it a new title?
 
I just had another crash. However, prior to crashing I saw this...
Code: 
humax# opkg info screensaver
Illegal instruction
humax# md5sum /bin/opkg /lib/libc.so.0 /lib/ld-uClibc.so.0
49c841fc813dd3f35c1d825980ba8045  /bin/opkg
dd69216a66b6b70d249ea6ce3f57fe53  /lib/libc.so.0
d8d9d222f8934cf6fb2235bf04103245  /lib/ld-uClibc.so.0
After eventually getting it to reboot...
Code: 
humax# md5sum /bin/opkg /lib/libc.so.0 /lib/ld-uClibc.so.0
b53c5460ae299f61bafae442c4a8c310  /bin/opkg
c0ca5235f4c79369c2750dd8f5bd8bab  /lib/libc.so.0
d8d9d222f8934cf6fb2235bf04103245  /lib/ld-uClibc.so.0
 
I get this :-
Code: 
humax# md5sum /bin/opkg /lib/libc.so.0 /lib/ld-uClibc.so.0
da58327820dfa2a06a33a3656127ee95  /bin/opkg
c0ca5235f4c79369c2750dd8f5bd8bab  /lib/libc.so.0
d8d9d222f8934cf6fb2235bf04103245  /lib/ld-uClibc.so.0

So I think opkg is corrupted, I would try a fix-disk
 
Ezra Pound said:
I get this :-
Code: 
humax# md5sum /bin/opkg /lib/libc.so.0 /lib/ld-uClibc.so.0
da58327820dfa2a06a33a3656127ee95  /bin/opkg
c0ca5235f4c79369c2750dd8f5bd8bab  /lib/libc.so.0
d8d9d222f8934cf6fb2235bf04103245  /lib/ld-uClibc.so.0

So I think opkg is corrupted, I would try a fix-disk
Click to expand...
You're probably just running different firmware versions.
I think xyz321's point was that the checksums changed on reboot indicating memory corruption.
 
I have just checked the MD5 hash of 'opkg' extracted from the hdf on a different system. It matches that of my second run above. I am running 1.02.29/2.12 BTW.
 
Ezra Pound said:
Ah, O.K. I am running 1.02.28/2.11 but I would have thought that pkgtools_1.0.0 was the same, so I guess opkg is seperate from pkgtools
Click to expand...
opkg is embedded in the custom firmware as it's needed for the bootstrap process. It changes with each firmware release.
 
You must log in or register to reply here.
Back
Top