HDR-FOX T2 Green screen of death?

[xyz321]

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]

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.

 

[xyz321]

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.

 

[Black Hole]

Consequential I reckon. Smoothing capacitor gone short circuit.

 

[xyz321]

My mistake, the bridge rectifier was fine. Anyway after much probing around, it suddenly decided to start working again.

All very strange.

 

[Black Hole]

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).

 

[Ezra Pound]

It doesn't really fit the thread title, How about My T2 has died or not as the case maybe

 

[xyz321]

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]

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?

 

[xyz321]

I just had another crash. However, prior to crashing I saw this...

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...

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]

I get this :-

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]

I get this :-

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.

 

[xyz321]

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]

You're probably just running different firmware versions.

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

 

[af123]

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.