I think the problem only occurs with 'always' schedules.
When 'always' schedules start two actual schedule handlers exist, 'the parent' which spawns the 'child'.
The 'child' schedule is the one that is recording the stream
If the 'child' schedule is stoped at anytime within the schedule time then 'the parent' will respawn a new 'child'.
SO when a schedule clash occurs with respect to time then the first schedule is stoped and the next actioned, the logs show this.
BUT with an 'always' schdule only the 'child' is stoped and then the 'parent' respawns another child which is causing the conflicting clash with the next already actioned schedule.
What is needed is that both the 'child' and 'parent' are removed form the schedule queue.
When 'always' schedules start two actual schedule handlers exist, 'the parent' which spawns the 'child'.
The 'child' schedule is the one that is recording the stream
If the 'child' schedule is stoped at anytime within the schedule time then 'the parent' will respawn a new 'child'.
SO when a schedule clash occurs with respect to time then the first schedule is stoped and the next actioned, the logs show this.
BUT with an 'always' schdule only the 'child' is stoped and then the 'parent' respawns another child which is causing the conflicting clash with the next already actioned schedule.
What is needed is that both the 'child' and 'parent' are removed form the schedule queue.