Crash after WebIf EPG schedule change & reboot

[MarmiteSandwich]

Hello all,
I recently joined the cause and installed the CFW on a recently purchased HDR Fox T2. All works well, except attempts to schedule EPG changes via the webif. After a change to the schedule, I receive the message to reboot, and the warning that this might require manual intervention. Go to the telly and watch the reboot happening - the channel that was playing briefly re-appears, followed by a blank screen and a message about the channel being scrambled or unavailable. I can then get the guide up, change to another channel (same message), but after a couple of remote key presses, the HDR-FOX just hangs and will only respond to a cold restart. Strangely, the WebIf still functions which suggests that the unit hasn't crashed, just the presentation to TV.

After restarting at the mains, the EPG change is there, but I have to power cycle the unit every time, which kind of limits the value of this feature. I haven't seen any other references to this issue, so I am wondering if I have some other problem? All suggestions welcome.

Regards,
Marmite

Web interface version: 1.0.7-7​

Custom firmware version: 2.19 (build 1815)​

Humax Version: 1.03.06​

​

 

[Ezra Pound]

There a three states the Humax can be in, they are on (and working), standby and a state known as 'half-awake' (See notes HERE), it is possible to log into the Humax when in half awake but there is no TV output. It might be worth checking the hard disk status with Webi-If >> Diagnostics >> Hard Disk, if this shows any errors there are more comprehensive tests that can be carried out

 

[Wallace]

I sure don't have that issue, and I have three HDR's.

As you say. If you make a scheduled recording via the WebIf the HDR needs to be rebooted. If you press the DISMISS button in the WebIf then the the timer you have just set will not become active UNTIL a reboot has been done. This can be via a power-cycle on the box itself, or via the REBOOT button in the WebIf. As it says, if you choose the later option there is a small chance the box won't wake up and you might have to press the power on button manually.

I have done this many, many times and never once have I had to do a COLD boot. On the odd occasion a warm boot, yes.

 

[Black Hole]

More info required: standard firmware version pre CF in particular, and what CF download used.

Edit: sorry, just noticed it at the bottom right corner of your post (novel!).

I see you are using 1.03.06 - does that mean new hardware or old? The aerial in and out sockets are paired vertically on new hardware and horizontally on old hardware.

Note that the CF on 1.03.06 should be considered "beta", and you are effectively one of the guinea pigs.

Strangely, the WebIf still functions which suggests that the unit hasn't crashed, just the presentation to TV.

The "standard" Humax application is a process which runs independently of the CF. That can crash without taking down the WebIF as well.

 

[MarmiteSandwich]

Vertical. Purchased 28/10/13 from Amazon. The CFW HTML makes the version numbers go to the bottom right! Tried to left justify it for a few mins then gave up.

Is this not quite right?: "If your Humax arrived running software version 1.03.06 then do not downgrade it to an earlier version. It is safe to install the customised firmware based on 1.03.06." Happy to try downgrading the Humax version if there is no risk and it might make a difference. I would quite like a WebIF scheduler that works.

I tried some experimenting with reboots - if I reboot from the WebIF WITHOUT changing the schedule, I could recover the unit by restarting from the remote. If I change the schedule, reboot from the WebIF, and then attempt to restart from the remote, it just hangs until I do a cold reboot.

BTW, I did a disk check via WebIF and got the following. Looks like I need more ventilation, but can't see that being the source of this problem.

Attributes
IDNameFlagsRaw ValueValueWorstThreshTypeUpdatedWhen Failed
1 Raw_Read_Error_Rate POSR-- 58422338 113 099 006 Pre-fail Always -
3 Spin_Up_Time PO---- 0 097 097 000 Pre-fail Always -
4 Start_Stop_Count -O--CK 276 100 100 020 Old_age Always -
5 Reallocated_Sector_Ct PO--CK 0 100 100 036 Pre-fail Always -
7 Seek_Error_Rate POSR-- 2830960 064 060 030 Pre-fail Always -
9 Power_On_Hours -O--CK 168 100 100 000 Old_age Always -
10 Spin_Retry_Count PO--C- 0 100 100 097 Pre-fail Always -
12 Power_Cycle_Count -O--CK 138 100 100 020 Old_age Always -
184 End-to-End_Error -O--CK 0 100 100 099 Old_age Always -
187 Reported_Uncorrect -O--CK 0 100 100 000 Old_age Always -
188 Command_Timeout -O--CK 0 100 100 000 Old_age Always -
189 High_Fly_Writes -O-RCK 0 100 100 000 Old_age Always -
190 Airflow_Temperature_Cel -O---K 47 053 044 045 Old_age Always In_the_past
194 Temperature_Celsius -O---K 47 047 056 000 Old_age Always -
195 Hardware_ECC_Recovered -O-RC- 58422338 049 044 000 Old_age Always -
197 Current_Pending_Sector -O--C- 0 100 100 000 Old_age Always -
198 Offline_Uncorrectable ----C- 0 100 100 000 Old_age Offline -
199 UDMA_CRC_Error_Count -OSRCK 0 200 200 000 Old_age Always -

 

[Black Hole]

The CFW HTML makes the version numbers go to the bottom right! Tried to left justify it for a few mins then gave up.

Top right of the edit tool bar you will find a control to switch to tags view (instead of WYSIWYG). The relevant tags can then be removed by hand. Alternatively, paste any text from an HTML copy into Notepad before copying it again and pasting into a forum post, to make sure any formatting is removed.

Is this not quite right?

It is right, yes. Users with the new hardware who have taken the risk of reverting to older firmware have found it renders the unit non-functional. There is an escape now in the form of a version of 1.03.06 that has been extracted, but this is not an official Humax download.

Looks like I need more ventilation

What makes you think that?

 

[Brian]

The CFW HTML makes the version numbers go to the bottom right! Tried to left justify it for a few mins then gave up.

It is very easy to Left justify text in the forum, I have adjusted them in your post #1 using the Align left button.

Your disk test results look fine though.

 

[MartinLiddle]

BTW, I did a disk check via WebIF and got the following. Looks like I need more ventilation, but can't see that being the source of this problem.

Nothing to worry about in the SMART data you posted. You can reduce the temperature by installing the fan package and adjusting the fan speed. Currently I am using a fan speed of 54% and that nicely keeps the disk below 50 C.

 

[Ezra Pound]

Looks like I need more ventilation, but can't see that being the source of this problem.

Attributes
IDNameFlagsRaw ValueValueWorstThreshTypeUpdatedWhen Failed

190 Airflow_Temperature_Cel -O---K 47 053 044 045 Old_age Always In_the_past
194 Temperature_Celsius -O---K 47 047 056 000 Old_age Always -

Your Humax has never over heated the 56 in line 194 is the maximum the unit has ever reached, this is normal. the 'In_the_past' in line 190 is not reporting a failure

 

[MarmiteSandwich]

Thanks for the advice on HTML and HDD, folks and for all the good work you do in supporting this device, with or without the manufacturer's support.

I guess I am stuck with the rebooting problem for the time being. I'll check back from time to time to see if a solution appears.
Marmite.

 

[Oatcake]

I have the same problem with my box. Reproducible every time via two methods...

1. If I make a schedule change and use the restart button in the WebIf, then the humax comes back up in this "zombie" mode whereby every channel is scrambled but I can still telnet/ use the WebIf. The power button on the remote no longer shuts down the box. The only way to get rid of this mode AFAIK is by cycling the power switch at the back.
2. I can also force the box into this state via the telnet interface. Choose "Restart into maintenance mode". Telnet back in and exit from maintenance mode. Upon reboot the channel is scrambled, etc.

I have however found a workaroundfor WebIf scheduling... always reboot the humax via the remote, NOT via the restart button in the WebIf. This way I have found that schedule changes are made correctly and the box does not restart with scrambled channels.

Therefore I think this problem might lie within the reboot facility of the CF.

I have tried:- reinstalling 1.03.06 and then returning to 1.03.06 CF 2.20; running "fix-flash-packages"; manual re-tune; clear epg data. No luck so far.

NOTE that the box didn't always behave like this. It started after a jump in the "Reallocated_Sector_Ct" from 0 to 8, and at the same time the partition table became corrupted. (It was a fun day sorting out the latter. I managed to save my recordings. I'm very grateful for the diagnostic mode!) If relevant to this discussion I can give you more info about this. (The box currently passes a quick disk check in diagnostic mode.)


HDR Fox-T2 RE (1TB ST1000VM002-1CT162), v1.03.06 with CF v2.20
(sorry I previously posted that I had the "GB" model, but the aerial in and out sockets are paired vertically, so I guess my box is "RE" - I have edited the line above to reflect this)

 

[Black Hole]

Software restarts do come with a warning, but previously we have only experienced the box not waking up again. If reboots don't work for you, just dismiss the "reboot required" message and do a manual one. The best option is to let the reboots occur during the normal on-off cycles, but obviously if the pending recording is imminent some kind of intervention is required.

You could always schedule an imminent recording using the normal interface of course, and then no reboot is needed at all!

 

[kev7378]

I have however found a workaroundfor WebIf scheduling... always reboot the humax via the remote, NOT via the restart button in the WebIf. This way I have found that schedule changes are made correctly and the box does not restart with scrambled channels.

I have exactly the same problem too, seen with

Web interface version: 1.0.various
Custom firmware version: 2.19/2.20
Humax Version: 1.03.06/new (RE) hardware
Loader: a7.34

First I briefly see a message onscreen saying “The channel is scrambled”, then that is replaced by “No programs are currently being broadcast on this channel” (for any channel it was on). The box then “locks-up” after one, maybe two key presses. Webif is still working tho but using it then and there to restart is not a always a fix.

The workaround is either, as you say, to use the remote to do the restarts. Alternatively the “button” centre front of the box. You need to wait for 10 seconds or so for it to leave the “stand-by only” state, otherwise it just comes straight back up without doing anything.

It seems easier to get the problem to happen using the Reboot System button on the Diagnostics page. Occasionally it happens with the scheduling reboot; I now use the workarounds so I don’t know how often that happens. I have done some poking around but didn’t discover anything or find a fix. af123 knows considerably more than me about the internals.

I think, if worried about simply removing the power to get it back or that a further Webif restart may not have cleaned out any problems even if it looks like it is okay again: “Safest” shut down of the locked box (if you’re paranoid, like me): Use System Reboot in the Webif and keep pressing the “off” button on the remote/front panel until the point where it has shown the channel and then dimmed it because it is going into standby; wait for one minute (so it is really in standby). Then power off at the back, count to ten and switch back on again.

But I recommend using the remote/centre button to restart until such time as we have a fix.