> Christian Wieninger wrote: > > perhaps this is too trivial, but why not create a daily or whatever > > timer as you suggested before with a special name like '@epgscan' and > > react on that? > > This would be a dirty ugly hack. There must be some pseudo-recording > running so VDR does not restart the recording over and over again. And > then we'll end up with a recording hack that looks like a timer but does > not block devices and does not write to disk and has no recording folder > and and and... > > 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. 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. 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 for realy using a KISS principle. The only benefit of scripting is that more people tend to write and change scripts that writing plugin or extend VDR code. The second is 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. Of couse Klaus should be one deciding the way to implement it but he should be more open here to stimulate more people to contribute to VDR. It's like Linux and Linus, the first is a scaling system the second not. Same for VDR and Klaus ;-) 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. kind regards Peter
