Thanks for the feedback and I managed to replicate this on my side.
Essentially if I had a schedule set to disable QoS at noon and it rebooted at 12:30 (for example), it would not actually "startup" FlexQoS since it has a check for QoS being enabled at startup otherwise it skips, and the last state was having QoS disabled before the reboot.
Code:
Sep 27 11:58:56 FlexQoS: /jffs/addons/flexqos/flexqos.sh (pid=16848) called in unattended mode with 1 args: -start
Sep 27 11:58:56 FlexQoS: Adaptive QoS is not enabled. Skipping FlexQoS startup.
This caused the bug you were seeing.
I had 2 choices which was remove the check from the startup function, but I believe it's there for good reason. (So that we don't attempt to apply any policies while QoS is disabled.)
My other choice which is what I elected to do was re-ordered and organized the flow for the startup sequence so it always starts QoS if you have a schedule configured.
This allows FlexQoS to startup normally, and then at the end I apply any custom schedules which may (or may not) re-disable QoS depending on the current time.
Please update to the latest develop version to test again (make sure you have QoS enabled when you do so):
Code:
sh /jffs/addons/flexqos/flexqos.sh develop