• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Register of Weird Crash Symptoms

Symptoms foreshadowing wizard after next restart:
  • package that depended on running a program from /mod/etc/init.d didn't appear to be working;
  • (special case of above) wi-fi with hidden SSID didn't get connected, but could be connected manually (from the on-screen menu).
 
:eek:

Suddenly stopped outputting HDMI. VFD showed it was responding to handset input (eg change channel, bring up menu), but TV insisted there was no signal on the input. Rebooting the HDR-FOX went through the TV saying there was no connection to that input (not the same as no signal), then the Humax splash screen followed by normal operation.

(HDR3, for the record)
 
Black Hole said:
Rebooting the HDR-FOX went through the TV saying there was no connection to that input (not the same as no signal), then the Humax splash screen followed by normal operation.
Click to expand...
Replace HDR-FOX with FVP-5000T and I've seen that with my Humax. Don't think I've seen it pack up whilst running. Humax comms problem that was never solved?
 
EEPhil said:
Replace HDR-FOX with FVP-5000T and I've seen that with my Humax... Humax comms problem that was never solved?
Click to expand...
I don't think so. It seems reasonable that the TV can detect nothing on the HDMI port ("cable not connected"} or something but no video ("no signal").

This is, however, the first time I have ever noticed loss of HDMI with no other apparent symptom.
 
Green screen hang on HD Fox-T2. After restart using the hidden front panel button, WiFi had to be forcibly reconnected and the HDD had to be re-enabled for recording.
 
BH - I see this from time to time - I've always assumed it was my HDMI switch box causing the issue but a cold restart is always needed.
Ocasionally cycling power on the monitor brings it back but not often.
Incidently _ I had a permanent record issue as in the other thread myself last night - the box was left and it cured itself about 4am.
(That one I dont recall seeing before).
 
Main box was doing a YT download which suddenly stopped. TV RX working OK, as is the on-screen interface and can play recordings OK.
Network appears to be dead (no ping or anything), but packet sniffing on the switch interface shows it's still transmitting (Samba UDP 138 and DLNA stuff on 1900). So I guess it's the network receive side that's got upset by something.
Power cycled it and it crashed after 13 seconds on reboot. Second reboot OK.
 
What is the cause of a locked database file? I presume some process had it reserved, and then a crash (or some other event, such as a bug) resulted in it not being unreserved. Might this explain random wizards?
 
Perhaps some thread in the settop program (the only process that lsof thought had the DB file open) has locked it and hung, such that when the program shuts down it updates the DB file with junk and causes DB to be reinitialised on the next startup. But the other symptoms I listed aren't obviously explained by that.
 
My HDR4 has been crashed (or so I've now discovered) for some days, but there's nothing "weird" about that.

What's weird is that it would not boot, it repeatedly got stuck at "STARTING SYSTEM" when power-cycled... until I removed the UPD occupying the front socket. The rear socket has a WiFi dongle in it.

Re-installing the UPD has not affected anything, I will observe for recurrences (although I do not habitually have that UPD plugged in).
 
Black Hole said:
My HDR4 has been crashed (or so I've now discovered) for some days, but there's nothing "weird" about that.

What's weird is that it would not boot, it repeatedly got stuck at "STARTING SYSTEM" when power-cycled... until I removed the UPD occupying the front socket. The rear socket has a WiFi dongle in it.

Re-installing the UPD has not affected anything, I will observe for recurrences (although I do not habitually have that UPD plugged in).
Click to expand...

So because it had a UPD it was looking for an update file presumably, but didn't continue booting when it couldn't find it.
 
Unusually (I don't recall it ever happening before) my HD-FOX just stopped producing any HDMI output! TV reported "no signal". WebIF still running, I used it to reboot.

TV flashed up a slightly pink screen before the Humax splash, then white, then pink again... and back to normal.
 
My HD crashed a couple of weeks ago while I was elsewhere. No response on the network. When I got back and looked at the HMDI out, it was a very dark grey with some sort of faint wavy line shimmering. A press of the reset button fixed it of course.
Black Hole said:
I really must get around to implementing my nightly timered brief power cut (within a power-off schedule), but mechanical timeswitches can drift (especially if there is a real power cut). Maybe Gosunds...
Click to expand...
I've got one of those Tapo P100 smart plugs on the above now, which don't have those drawbacks (just others instead).
They're only a tenner from Toolstation at the moment, £2 cheaper than when I got the first one for elsewhere. They can be programmed to do what you want, but everything's set up via a phone app.
You can also control them externally with a bit of Python thereafter, should you so desire (although Python always seems like harder work than it should be, to me anyway). I still run them on a separate SSID and VLAN though, so they can't get to the rest of the LAN.
 
After a WebIF reboot, stuck with "Reboot..." on the VFD and frozen video on HDMI, and yet WebIF running but reporting "cannot find humaxtv process" as the status. Repeating WebIF reboot achieves nothing (it seems to progress normally in the web browser and reloads the WebIF main page after the delay timer), but nothing happens on the box). Power cycle required.
 
The code path for this is:
Code: 
       feedback  "Reboot..." "REBT"
        /etc/init.d/S90settop shut
        /bin/sync
        /sbin/reboot
        exit 0
It would have been interesting to see what a repeat of /sbin/reboot did. I've had a failure to reboot using this recently as part of testing something else.
There is potentially a bigger hammer that can be wielded.
 
One of my HDRs has failed to restart properly after the 3am tunefix-update reboot:
Code: 
humax# service
Name                 Installed  Autostart  Running  
----                 ---------  ---------  -------  
betaftpd             Yes        Yes        No       
cifs                 Yes        Yes        No       
cron                 Yes        Yes        No       
dropbear             Yes        Yes        No       
epg                  Yes        Yes        No       
lighttpd             Yes        Yes        No       
nfs                  Yes        Yes        No       
ntp                  Yes        Yes        No       
recmon               Yes        Yes        No       
samba                Yes        Yes        No       
snmpd                Yes        Yes        No       
virtual-disk         Yes        Yes        Yes      
webshell             Yes        Yes        No
but the humaxtv process itself is alive and functioning, just nothing much else.
A look at the running processes gives this:
Code: 
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:02 init     
   26 ?        Ss     0:00 /bin/sh /etc/init.d/rcS
  105 ?        Ss     0:00 /sbin/bootstrapd init.html
  108 ?        S      0:00 /usr/bin/shellinaboxd -t -p 88 -s /:root:root:/:/bin/tmenu -s /cli/shell:root:root:/:/bin/tmenu
  149 ?        S      0:00 /usr/bin/shellinaboxd -t -p 88 -s /:root:root:/:/bin/tmenu -s /cli/shell:root:root:/:/bin/tmenu
  158 ?        S      0:00 /usr/bin/dnsmasq
  165 ?        SNs    0:00 /sbin/utelnetd -l /bin/sh -p 23 -d -b
  301 ?        S      0:00 /bin/sh /etc/init.d/S90settop start
  349 ?        Sl    40:40 /usr/bin/humaxtv
  744 ?        S<     0:00 /bin/sh /etc/mdev/run-and-gun
  909 ?        Ss     0:00 udhcpc -t 5 -T 10 -p /var/lib/humaxtv/udhcpc.eth0.pid -i eth0
 1018 ?        S<     0:00 /bin/sh /etc/mdev/run-and-gun
 1033 ?        S<     0:00 /bin/sh /etc/mdev/run-and-gun
 1067 ?        S<     0:00 /bin/sh /etc/mdev/run-and-gun
 1187 ?        D<     0:00 date +%d/%m/%Y %H:%M:%S %z
 1199 ?        D<     0:00 date +%d/%m/%Y %H:%M:%S %z
 1200 ?        D<     0:00 date +%d/%m/%Y %H:%M:%S %z
 1204 ?        D<     0:00 date +%d/%m/%Y %H:%M:%S %z
 2071 pts/0    SNs    0:00 /mod/bin/busybox/sh -l
 2372 pts/0    RN+    0:00 ps ax
The odd things are all those "date" commands which are part of run-and-gun, which is to do with mounting disk partitions etc. Everything seems to be mounted correctly, but all those "date"s are unkillable. RnG itself can be killed but doesn't unblock anything.
Having looked it up, "D<" apparently means "Uninterruptible sleep (usually IO), high priority". I presume this is where it's trying to output to /tmp/rag.log, which has the last message for each mount point as "still waiting..." and is therefore incomplete. Can't imagine what the blocker is to this IO.
Attempts to software reboot failed, so had to power cycle it, which has restored normal operation.
 
My HDR3 seems the most dicky in my household. Today I've switched on the telly to catch up with the numbers rounds on Countdown (as a daily recording) only to find it stuck on LCN250 (the default) with no sign of a recording in progress and no response to the remote or WebIF... and yet the time is displayed correctly on the Red Button screen!

A hang would normally freeze video, but I'm guessing that the Red Button screen is constructed from data rather than transmitted video frames so whatever daemon is doing that must still be running unaffected by the rest of the system having crashed!

And yet RS is saying it's still phoning home!
 
You must log in or register to reply here.
Back
Top