pending schedule command - how long does this take?

G

geordie

Member
Hi

Had a Crash error "Crash - wait" so followed the instructions on here and it cleared. When I then checked the schedule, my pending actions are still there but my scheduled events are empty. If I look at the status of those pending events, they say "pending schedule command". How long does this command take to run and how can I tell if something is wrong? If something is wrong, how can I fit it?

Recordings added through the Humax itself appear in the scheduled events as expected.

And the activity.log shows a lot of entries for Scheduled after the Crash reboot but nothing in the scheduled events.

Thanks
 
There are two answers to that, according to whether Real Time Scheduling is enabled in WebIF >> Settings >> Advanced Settings (default is off).

Without RTS, the WebIF is unable to alter the schedule database while settop is running (the Humax standard functional code). Therefore WebIF/RS schedule alterations are queued until the next boot, and actioned before settop starts up. This was how we had to work to start with.

RTS came along later, and is still not totally bug free* (that's why it defaults to off). I'm not clear how it works, but af123 found a way to inject database alterations without stopping settop. WebIF schedule alterations (with RTS) should be immediate, RS alterations are downloaded when the WebIF "phones home" (every 10 mins by default).

So:
  1. Do you have RTS enabled?

  2. Is the "pending" on RS or WebIF?
* The bug is "runaway recordings" - very occasionally, a recording scheduled using RTS starts correctly but fails to stop, only ending by manual intervention or when the disk fills up.
 
I cannot see Real Time Scheduling is enabled in WebIF >> Settings >> Advanced Settings (default is off).

I've got
show development...
rotate logs
how many logs
delete old logs
disable telnet menu
 
1608418856632.png

OK, So:
  1. Have you always needed to reboot to schedule from WebIF/RS, or do you believe you have been using RTS in the past?

  2. Did you run WebIF >> DIagnostics >> fix-flash-packages after the crash?

  3. In WebIF >> Package Management >> Installed (with Show Advanced Packages clicked at top right), is nugget listed?
Screen grabs of your problems would help enormously.
 
geordie said:
I cannot see Real Time Scheduling is enabled in WebIF >> Settings >> Advanced Settings (default is off).

I've got
show development...
rotate logs
how many logs
delete old logs
disable telnet menu
Click to expand...
What version of the firmware and webif do you have installed (shown on Homepage and Diag page)
 
MymsMan said:
What version of the firmware and webif do you have installed (shown on Homepage and Diag page)
Click to expand...
Web interface version: 1.4.4-10
Custom firmware version: 3.13 (build 4028)
Humax Version: 1.03.12 (kernel HDR_CFW_3.13)
Loader Version: a7.31

I will look into the fix-flash etc
 
Your WebIF is a little out of date, I'm on 1.4.8-9 (that's a beta build, the latest non-beta is 1.4.8-8). However, if you think you have been using RTS in the past, it can't be the WebIF version that's the problem.

I would normally say update to baseline, but in this case I think we should try to fix what you've got before updating.
 
Last edited:
Black Hole said:
Your WebIF is a little out of date, I'm on 1.4.8-9 (that's a beta build, the latest non-beta is 1.4.8-8). However, if you think you have been using RTS in the past, it can't be the WebIF version that's the problem.

I would normally say update to baseline, but in this case I think we should try to fix what you've got before updating.
Click to expand...

The final install I used was HDR_FOX_T2_1.03.12_mod_3.13.zip - (28/04/2017
 
That's not the same thing. The "install" you are referring to is what gets burned into Flash - but there's a whole load more (WebIF etc) that is downloaded to HDD as the next stage, and is updated from WebIF >> Package Management >> Check for updates (and then listed on the Upgrades tab). Clicking "Upgrade all packages" updates all the downloaded packages, or installing the auto-update package keeps everything updated automatically (but not the base firmware).

However, if you think you had RTS before, this is barking up the wrong tree.

If you've never had RTS (that you are aware of), it might simply be that you are too far out of date - in which case this
Black Hole said:
the WebIF is unable to alter the schedule database while settop is running (the Humax standard functional code). Therefore WebIF/RS schedule alterations are queued until the next boot, and actioned before settop starts up.
Click to expand...
is what you should expect.

Update: I just checked and RTS was introduced in August 2016. That significantly predates WebIF 1.4, so the version is a red herring.

Black Hole said:
OK, So:
  1. Have you always needed to reboot to schedule from WebIF/RS, or do you believe you have been using RTS in the past?

  2. Did you run WebIF >> DIagnostics >> fix-flash-packages after the crash?

  3. In WebIF >> Package Management >> Installed (with Show Advanced Packages clicked at top right), is nugget listed?
Click to expand...
 
Last edited:
Black Hole said:
That's not the same thing. The "install" you are referring to is what gets burned into Flash - but there's a whole load more (WebIF etc) that is downloaded to HDD as the next stage, and is updated from WebIF >> Package Management >> Check for updates (and then listed on the Upgrades tab). Clicking "Upgrade all packages" updates all the downloaded packages, or installing the auto-update package keeps everything updated automatically (but not the base firmware).

However, if you think you had RTS before, this is barking up the wrong tree.

If you've never had RTS (that you are aware of), it might simply be that you are too far out of date - in which case this

is what you should expect.

Update: I just checked and RTS was introduced in August 2016. That significantly predates WebIF 1.4, so the version is a red herring.
Click to expand...
nugget is installed
 
I will have to be methodical about this. It started with the Crash and I followed the guidance. Then, because as far as I knew, the crash fix did not install the latest version of the custom firmware, I installed the latest version I could find.

I did a schedule restore and lots in pending but nothing in scheduled. That I can understand, but the way every planned action says Pending schedule command - and this has been the case for hours. I just don't understand what has happened.
 
This is painful. Just run the fix-flash-packages diagnostic, for God's sake, as has already been suggested twice.

And once you've done that then enter this command from a command prompt (Webshell, telnet or, ssh), having selected "cli" from the menu:
touch /var/lib/humaxtv/mod/no_plugin_autodisable
 
prpr said:
This is painful. Just run the fix-flash-packages diagnostic, for God's sake, as has already been suggested twice.

And once you've done that then enter this command from a command prompt (Webshell, telnet or, ssh), having selected "cli" from the menu:
touch /var/lib/humaxtv/mod/no_plugin_autodisable
Click to expand...
Done both. What now?
 
geordie said:
following an auto update at 4:30.
Click to expand...
The regular 4.30 thing is an automatic search for over-the-air updates to the Humax firmware, and there have been none of those for years. If there were, an update would wipe the custom firmware - so CF users should have disabled the 4.30 schedule (not essential now).

The 4.30 OTA search did not fix your problem. If the machine was in standby and booted to perform an OTA search, the boot fixed your problem.

See Preventing External Events from Disturbing the CF (click).

geordie said:
I did a schedule restore and lots in pending but nothing in scheduled.
Click to expand...
A manual schedule restore operation has to be followed by a reboot. There is a flag at the top of the WebIF page telling you to do so, after a restore. RTS has no effect on this.

geordie said:
Then, because as far as I knew, the crash fix did not install the latest version of the custom firmware, I installed the latest version I could find.
Click to expand...
This is completely unnecessary under these circumstances. There is a fundamental difference between updating the base CF (a manual operation involving plugging in a UPD containing a .hdf file, forcing a reboot, then "downloading" and "programming" on screen), and updating the packages (including WebIF - which is just another package). The packages need updating separately from the CF, and far more frequently (unless you "don't fix what ain't broke"). Actual CF updates are rare.

All CF users need to be aware of the differences between CF and packages. It might help for you to read Quick Guide to Custom Firmware (click).

prpr said:
touch /var/lib/humaxtv/mod/no_plugin_autodisable
Click to expand...
For information: that had no effect of your problem, it just helps it not be a problem again in the future by turning off a feature originally intended to prevent continuous crash cycles. Some packages have elements resident in Flash, and these packages get disabled in case they were the cause of the crash (which disables some functionality - including nugget, which implements RTS). Experience indicates this precaution is not necessary (because af123 has already screened out these problems during alpha testing), but comes with a risk that a future bug could (potentially) be very difficult to counter. Beta testers might be best advised not to set no_plugin_autodisable (make your own minds up on that one, but be aware of the risk).

The alternative is having to run fix-flash-packages after a double-crash (as flagged up in WebIF) - not exactly arduous. Crashes happen, whether you like it or not (particularly when the HDR-FOX has Internet access).

geordie said:
I will have to be methodical about this. It started with the Crash and I followed the guidance.
Click to expand...
Always necessary to be methodical.

I'm trying to understand why you went the route you did. What guidance? Be precise. If it was this:

Steps for Resolving HDR-FOX Crash/Reboot Issues (click)

...you need to understand that one crash does not represent an "issue". My machines all crash from time to time, all I do is reboot them, and run fix-flash-packages only if necessary. A crash "issue" is when it keeps doing it.
 
Last edited:
Black Hole said:
The regular 4.30 thing is an automatic search for over-the-air updates to the Humax firmware, and there have been none of those for years. If there were, an update would wipe the custom firmware - so CF users should have disabled the 4.30 schedule (not essential now).

The 4.30 OTA search did not fix your problem. If the machine was in standby and booted to perform an OTA search, the boot fixed your problem.

See Preventing External Events from Disturbing the CF (click).


A manual schedule restore operation has to be followed by a reboot. There is a flag at the top of the WebIF page telling you to do so, after a restore. RTS has no effect on this.


This is completely unnecessary under these circumstances. There is a fundamental difference between updating the base CF (a manual operation involving plugging in a UPD containing a .hdf file, forcing a reboot, then "downloading" and "programming" on screen), and updating the packages (including WebIF - which is just another package). The packages need updating separately from the CF, and far more frequently (unless you "don't fix what ain't broke"). Actual CF updates are rare.

All CF users need to be aware of the differences between CF and packages. It might help for you to read Quick Guide to Custom Firmware (click).


For information: that had no effect of your problem, it just helps it not be a problem again in the future by turning off a feature originally intended to prevent continuous crash cycles. Some packages have elements resident in Flash, and these packages get disabled in case they were the cause of the crash (which disables some functionality - including nugget, which implements RTS). Experience indicates this precaution is not necessary (because af123 has already screened out these problems during alpha testing), but comes with a risk that a future bug could (potentially) be very difficult to counter. Beta testers might be best advised not to set no_plugin_autodisable (make your own minds up on that one, but be aware of the risk).

The alternative is having to run fix-flash-packages after a double-crash (as flagged up in WebIF) - not exactly arduous. Crashes happen, whether you like it or not (particularly when the HDR-FOX has Internet access).


Always necessary to be methodical.

I'm trying to understand why you went the route you did. What guidance? Be precise. If it was this:

Steps for Resolving HDR-FOX Crash/Reboot Issues (click)

...you need to understand that one crash does not represent an "issue". My machines all crash from time to time, all I do is reboot them, and run fix-flash-packages only if necessary. A crash "issue" is when it keeps doing it.
Click to expand...
Yes regarding the steps I followed. I think the issue was created as I was using the webif scheduler and might have been adding and removing events a bit randomly.

Thanks for the explanation on the updates. I just assumed that generally the latest webif comes with the last Zip file but the auto-update did seem to fix things.

As for the reboot, yet I did that but it made no difference. However, that seems because something else needed updating because the 4:30 update fixed it. Theflash-fix-package did make changes but not everything to resolve the issues.
 
You must log in or register to reply here.
Back
Top