HDR-FOX T2 Green screen of death?

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.
 

Black Hole

May contain traces of nut
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.
 
OP
X

xyz321

Well-Known Member
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.
 
OP
X

xyz321

Well-Known Member
My mistake, the bridge rectifier was fine. Anyway after much probing around, it suddenly decided to start working again. :)

All very strange.
 

Black Hole

May contain traces of nut
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).
 
OP
X

xyz321

Well-Known Member
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.
 

Black Hole

May contain traces of nut
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?
 
OP
X

xyz321

Well-Known Member
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
 

Ezra Pound

Well-Known Member
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
 

af123

Administrator
Staff member
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
You're probably just running different firmware versions.
I think xyz321's point was that the checksums changed on reboot indicating memory corruption.
 
OP
X

xyz321

Well-Known Member
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.
 

af123

Administrator
Staff member
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
opkg is embedded in the custom firmware as it's needed for the bootstrap process. It changes with each firmware release.
 
Top