Register of Weird Crash Symptoms

OP
Black Hole

Black Hole

May contain traces of nut
I used WebIF to access the "headless" HDR-FOX I use to make recordings from radio and convert for later consumption in the car. Some scheduled recordings were missing. The WebIF schedule browser showed no active EPG entries for them (when they should have been rescheduled for next week as continuing series).

Foolishly I ran fix-flash-packages and thereby killed ir (there is a problem with the ir package at the moment which means it can't be reinstalled when fix-flash-packages deletes it and tries to reinstate it).

Rebooting fixed it: a crash must have stopped settop but not WebIF, so the EPG wasn't being updated and recordings were not being made, despite still having access to WebIF.
 
Last edited:

/df

Well-Known Member
...
Rebooting fixed it: a crash must have stopped settop but not WebIF, so the EPG wasn't being updated and recordings were not being made.
One hopes that it must have hung as the system should have rebooted if settop crashes.

My most common weirdness ...

Video partition (at least) gets marked as RO, settop possibly hangs (audio can continue, video freezes, no response to remote or buttons). On crashing or being killed or s/w reboot forced, HDMI doesn't work. Power cycling restores it.
 
OP
Black Hole

Black Hole

May contain traces of nut
The same "headless" HDR-FOX as mentioned perviously: it's on WiFi and I couldn't get WebIF access even though the VFD was scrolling as usual. However, it was not responding to handset or front panel inputs, and the TV just gave a green screen.

A power cycle restored normal function.
 
OP
Black Hole

Black Hole

May contain traces of nut
I was watching a recording, and went into the menu system to check a detail, but couldn't exit. The HDR-FOX was stuck with the menu on-screen, but the recording continuing to play in the background. No response to handset or front panel controls, but WebIF working and VFD scrolling. No response to WebIF virtual remote.

After a power-cycle all back to normal, but there was no resume offered on the recording.
 

prpr

Well-Known Member
I've had apparent IR lockups several times as well. Only way out is to power cycle, which is a nuisance if it's recording of course.
 

sine24

Member
It seems to have happened twice recently: playng back a recording the t2 crashed, no webif. I've had crashes before but don't remember one during playback.
 
OP
Black Hole

Black Hole

May contain traces of nut
This one really has me scratching my head. It's not exactly a "crash" or a "freeze", and I was ready to declare it a hardware failure (my "HDR3"):

"No programmes are currently being broadcast on this channel" (despite that not being correct, and signal quality showing 100%). The strange thing was, if I changed service (any service, any mux), I got programme for maybe 20 seconds and then back to black. Signal detection showed OK on all muxes.

Tuner? I set it recording and then switched to another mux - same thing. Tuner test in the service menu showed OK on all muxes on both tuners.

Heat? Exhaust was warm, but the fan was running and Sysmon showed a steady 43deg.C. Maybe it needs dusting out? Not easy - I have the (captive) mains lead cable-tied with other leads (a mains inlet socket would be a useful mod after all!).

So, just for the hell of it I tried a (quick and easy) power cycle... not long enough to have alterered the temperature, but in the hour since the problem has not recurred. All recordings made since (and including) 7.55am on Thursday 18th Feb are broken (0 mins), the previous good recording was completed on 7.04pm Wednesday.

What could cause this? The only thing which occurs to me is that the decoder needs periodical commands to keep it alive (can't imagine why), and the individual process which sends those periodic refreshes had crashed (leaving everything else alive). We know that if settop crashes, at least the audio stream continues to be delivered to the HDMI (which was not the case here), so maybe the continuation of audio requires settop to have crashed so it can't notice something wrong and put up an on-screen message.
 
OP
Black Hole

Black Hole

May contain traces of nut
HDR1: Following a WebIF reboot, WebIF working but the "ticker" shows "Cannot find humaxtv process":

1614415545550.jpeg
...and ditto on the WebIF >> Diagnostics >> Reboot screen:
1614415688806.jpeg

SMB server working (can play HDR1 recordings on other machines). Live picture frozen. Front panel shows "Reboot...":
1614416013387.jpeg

Reboot from WebIF >> Diagnostics does not fix it, I suspect nothing actually happens. Power-cycle fixed it.

I had been fiddling with /mod/etc/init.d, hence had performed a WebIF reboot. Live TV froze at that time (Red Button), so I think the reboot failed and got stuck without actually rebooting.

There has been a lot of alteration lately with beta firmware and beta WebIF, but I have been unable to reproduce this on my other machines with the same firmware and WebIF. I have also been unable to reproduce this on HDR1, despite recreating my init.d fiddling.
 

/df

Well-Known Member
So, fiddling with some configuration database stuff at boot-up (xinit), one can end up with a 4:3 letterbox display on a blue background with country set to Australia and the channel-toggle function of Back on the I-plate disabled. Then setting Preferences>Video>Screen Ratio causes an actual CrASh. Factory Default restores the expected functionality.

This is a comparison of TBL_MENUCONFIG from setup.db for the bad and good cases (the same comparison for TBL_USERCONFIG is uninteresting):
Code:
attach '/var/lib/humaxtv/setup.db' as su1;
attach '/mod/tmp/bak/humaxtv/setup.db' as su2;
select weird.*, good.itemValue, good.itemText from su2.TBL_MENUCONFIG weird, su1.TBL_MENUCONFIG good 
     where weird.itemName = good.itemName and 
                weird.itemValue||weird.itemText <> 
                     (select itemValue||itemText from su1.TBL_MENUCONFIG where itemName = weird.itemName);

4|MENU_LANG|0||(null)|11|
6|SOUND_DIGITALOUTPUT|0||(null)|3|
10|RESOLUTION|12||(null)|15|
12|EMPTY_BOX_COLOR|0||(null)|1|
15|AUTOMATIC_POWER_DOWN|0||(null)|1|
16|WLAN_IS_CONNECTED|1||(null)|0|
19|AUDIO_LANG|0||(null)|11|
28|INFO_DISPLAY_TIME|0||(null)|10000|
29|OSD_TRANSPARENCY|0||(null)|1|
37|FAV_CUSTOM_STR01|1|Faves|(null)|0|Favourite 1
38|FAV_CUSTOM_STR02|1|FavesHD|(null)|0|Favourite 2
41|FAV_CUSTOM_STR04|1|Favourite 4|(null)|0|Favourite 4
44|SUBTITLE_LANG|0||(null)|11|
48|POWER_ON_CHANNEL|131098||(null)|-1|
49|TIME_VOLUME|10||(null)|0|
For items whose name includes LANG, 0 must be Australia (first, or zeroth, in the list of countries in the hidden menu's Country pull-down) and 11 must be England.

EMPTY_BOX_COLOR seems to determine whether unpainted (no signal) areas are blue (0) or black (1), but doesn't have a corresponding UI, I think.

RESOLUTION presumably maps to V.Fmt.

TIME_VOLUME is a mystery, though it is known to the settop blob.

The breakage of channel toggle also eludes explanation.

After further investigation, apparently this is what happens when you accidentally set all itemValues to 0 in TBL_MENUCONFIG.
 
Last edited:

/df

Well-Known Member
HDR1: Following a WebIF reboot, WebIF working but the "ticker" shows "Cannot find humaxtv process":
...
I had been fiddling with /mod/etc/init.d, hence had performed a WebIF reboot. Live TV froze at that time (Red Button), so I think the reboot failed and got stuck without actually rebooting.
Apparently "Cannot find humaxtv process" was an accurate diagnostic. Presumably rebooting or reinstalling made everything work again.
 

bottletop

Active Member
Was watching live TV on HDR. Nodded off and woke up to blank screen, no sound. No WebIF and pinging the ip didn't work. Switched HDMI sources and back again on TV, still blank. Didn't respond to any IR handset functions. Had to power off and on the HDR
 
Last edited:

MymsMan

Ad detector
A runaway recording that wasn't!

Not a crash as such but required reboot to resolve

Yesterday I had what appeared to be a runaway recording, It was listed as an active recording in the webif long after it should have completed and subsequent recordings failed to start recording,
It couldn't be stopped by the remote but when I rebooted the machine I found the recording was actually the shorter by about 5 minutes than the correct length and was truncated rather than runaway
 
Top