peter.dittmann@xxxxxxxxxx wrote: >> The alternative would be to implement a generic task scheduler and make >> timers one special type of schedule. This would get REALLY big. > > Yes, but it will be the much better design. > > It will open the option to do VDR related timed and maintainance tasks. There must be some limit. IMHO VDR is a video recorder, not a task scheduler. And I think that Klaus probably agrees with that. > Don't reply this should be external scripts, as there is no way > external scripts know what state VDR currently has without a lot more > complexity. What additional internal state info do you need? Providing interfaces to cooperate with external schedulers should be no problem. > These are EPG scans (internal, infosatepg, nextview), sleeptimers, > switchonly timers, cleanup tasks of plugins and so on. Think about > external EPGs, especilly the ones that need VDR to tune to a channel, > like infosatepg or nextview. This is painfull hack doing his outside > VDR as these tasks mutually collide with VDRs internal activities and > need to be integrated Do you suggest to put all these EPG collectors as integral schedule events into core VDR??? At most, such things may be done as plugin. And for plugins, the ability to wake up at a non-timer time was already suggested. > for realy using a KISS principle. In my eyes, KISS also applies to VDR itself. Meaning, why add a full-featured scheduler to VDR that VDR doesn't need? > also cause by Klaus's reluctance to take over patches. Where there > are patches there is need to change some VDR behaviour, so this > behaviour should be changed. In limits, yes. But Klaus being very conservative on integrating patches and features is one of the reasons why VDR is still a very stable and easy to use program. What sounds like a nice enhancement now may soon turn into a dead end, a burden kept for compatibility. There are lots of programs that are overloaded with features that no one really knows, with an user interface to get lost in it. > The idea to create now a "external" Shutdown class by a second person > seems like a good starter. It should be done for other > functionalities too. This is not the first bigger chunk of work contributed by others, and definitely not the first smaller feature that was contributed. Its also a matter of engagement: If you start off with "I'll do it as independent patch, Klaus wont add it anyway", then you'll get what you want. The reason I am working on this is that AFAIK Klaus doesn't use the shutdown mechanisms, and the code really needed an overhaul by someone who's interested in it. Cheers, Udo
